\documentclass{scrreprt}


\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
\usepackage{listings}\lstset{numbers=left, numberstyle=\tiny, numbersep=5pt}
%\usepackage{scrhack}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{amssymb}


\usepackage{fancyhdr}
\pagestyle{fancy}
\usepackage[svngames]{xcolor}

\usepackage{tocloft}

\lstset{language=java,
basicstyle=\small,
keywordstyle=\color{blue!80!black!100},
identifierstyle=,
commentstyle=\color{green!50!black!100},
stringstyle=\ttfamily,
breaklines=true,
numbers=left,
numberstyle=\small,
frame=single,
backgroundcolor=\color{blue!3},
caption={Java-Code},
tabsize=2,
showstringspaces=false} 

\newcommand{\jo}{\textcolor{green}{\checkmark}}
\newcommand{\no}{\textcolor{red}{X}}

\begin{document}
	\begin{center}
	
		\Large
		Eberhard Karls Universität Tübingen\\
		Wilhelm-Schickhard-Institut für Informatik\\
		Lehrstuhl Programmiersprachen und Übersetzer\\
	
		\vspace*{25mm}		
		
		\huge
		Bachelorarbeit Informatik\\
		
		\vspace*{1cm}
		
		\Huge Course Information System - CIS3\\

		\vspace*{1cm}

		\LARGE
		Thorsten Ludwig\\

		\vspace*{1cm}	
		
		\today\\

		\vspace*{3cm}
	
		\LARGE
		Gutachter\\
		\Large
		Prof. Dr. Herbert Klaeren\\
		Wilhelm-Schickhard-Institut für Informatik\\
		Universität Tübingen\\

		\vspace*{1cm}		
		
		\LARGE
		Betreuer\\
		\Large
		Julia Trieflinger\\
		Wilhelm-Schickhard-Institut für Informatik\\
		Universität Tübingen\\
	\end{center}
	\normalsize
%\newpage

\chapter*{Danksagung}
	Bedanken möchte ich mich bei Julia Trieflinger für ihre sehr gute und
	sehr intensive Betreuung.
	
	Desweiteren möchte ich mich bei Cordula Witzig, Ann-Kathrin Kraft und Sophia Dittes bedanken,
	die meine Arbeit korrekturgelesen und viele Anmerkungen gemacht haben.
\chapter*{Eidesstattliche Erklärung}
	Hiermit erkläre ich, dass ich die hier vorliegende Bachelorarbeit selbstständig verfasst
	und keine anderen als die angegebenen Quellen verwendet habe.
	
	\vspace{3cm}	
		
	Tübingen, der \today 
	
	\vspace{15mm}
	
	\underline{\hspace{4cm}}

\chapter*{Kurzfassung}
	
	Neben dem Halten einer Vorlesung fließt viel Zeit in dessen Organisation. 
	Um wiederkehrenden Administrationsaufwand zu verringern, wird seit dem Jahr 2000 am Fachbereich Informatik 
	das Course Information System (CIS) eingesetzt.
	CIS ist ein Verwaltungsprogramm von Studentendaten und eine Kommunikationsplattform. Studenten
	können sich im CIS informieren (sowohl fachlich als auch organisatorish) und den Punktestand ihrer
	Übung einsehen. Die aktuelle Version zwei des Systems nimmt bereits viel Arbeit ab, lässt aber noch Raum 
	für Verbesserungen offen. So lassen sich im CIS3 Punkte aus der Wertung nehmen, damit für alle Studenten
	die automatische Berechnung der Endnote möglich ist.
	In der vorliegenden Arbeit wird aufgezeigt, an welchen Stellen
	CIS2 verbessert werden kann. Außerdem wird das im Rahmen dieser Bachelorarbeit entwickelte CIS3 
	vorgestellt, welches einen ersten Schritt in diese Richtung geht.

\newpage

\tableofcontents

\vspace{5cm}

\listoffigures


\chapter{Einleitung}
		Das Abhalten einer Vorlesung umfasst meist mehr Arbeit als nur die Vorbereitung und das Lesen selber.
		Je nach Teilnehmerzahl ist der Organisationsaufwand immens. In dieser Bachelorarbeit
		soll das Course Information System (CIS) vorgestellt werden, mit dessen Hilfe der 
		Administrationsaufwand vermindert werden soll.
		
		Das CIS wird derzeit im Fachbereich Informatik an der Universität Tübingen eingesetzt.
		Es wird sowohl für Einführungsveranstaltungen mit über 200 Studenten als auch für kleinere
		Vorlesungen mit etwa 10 Studenten verwendet.
		
		Dabei wird in der Tübinger Informatik zu fast jeder Vorlesung eine begleitende Übung angeboten. 
		In den Übungen wird der Stoff der Vorlesung rekapituliert und es werden Übungsaufgaben besprochen.
		Die Übungsgruppen werden von Tutoren geleitet. Die Tutoren korrigieren die Übungsaufgaben,
		helfen den Studenten bei der Bearbeitung und beantworten Fragen zum Stoff der Vorlesung.
		
		Übungen tragen einen wesentlichen Teil zum Verständnis des Vorlesungsinhaltes bei,
		erzeugen aber auch viel Administrationsarbeit. Tutoren und Studenten müssen zu Übungsgruppen 
		zugeteilt werden. Die Übungsaufgaben müssen verteilt werden,
		die Lösungen, zum Teil in digitaler Form, eingesammelt und an die Tutoren weitergegeben
		werden. Die in den Übungsaufgaben erreichte Punktzahl der Studenten muss zentral notiert
		und später zur Benotung herangezogen werden. Ergeben sich Änderungen im Ablauf und andere Neuigkeiten
		zu der Vorlesungen, müssen die Studenten zeitnah informiert werden. Die Arbeit der Tutoren
		muss koordiniert und der Übungsbetrieb passend zur Vorlesung abgestimmt werden. Begleitendes Material
		zur Vorlesung wie Skripte oder Beispielcodes müssen den Studenten bereitgestellt werden.
		
		An dieser Stelle setzt das CIS an. Bei dem CIS handelt es sich um eine Internetplattform, 
		über die diese Administrationsarbeit verrichtet	wird. Es entstand im Jahr 2000 für die 
		Informatik I/II Vorlesungen \cite{HolgerGast2004}, 	kam aber schon bald in weiteren Vorlesungen 
		zum Einsatz. 2007 wurde es im Rahmen einer Studienarbeit \cite{Fleck2007} weiterentwickelt
		zur heutigen Form.
				
		Im CIS registrieren sich sowohl Studenten, Tutoren als auch Dozenten.
		Jede dieser Benutzergruppen hat eine eigene Sicht auf das CIS: 
		
		Studenten registrieren sich zu Beginn der Vorlesung und wählen dabei bevorzugte Übungsgruppentermine
		aus. Nach der Zuteilung zur Übungsgruppe erfahren sie Zeit, Ort und Tutor ihrer Übungsgruppe.
		Übungsaufgaben, die von den Dozenten veröffentlicht wurden, können heruntergeladen werden. Haben
		die Studenten die Übungsaufgaben bearbeitet, können sie die Lösungen für die Aufgaben hochladen.
		Die in den Übungsaufgaben erreichte Punktzahl ist für die Studenten einsehbar. 
		Gibt es Neuigkeiten zu den Vorlesungen, sind diese auf der Startseite sichtbar.
		
		Tutoren können zusätzlich die Studenten ihrer Übungsgruppe mitsamt E-Mail Adresse einsehen.
		Von den Studenten hochgeladene Lösungen können von den Tutoren heruntergeladen werden. 
		Nach der Korrektur lässt sich die von den Studenten erreichte Punktzahl eintragen. 
		Um alle Studenten der eigenen Übungsgruppe schnell zu erreichen, 
		lassen sich E-Mails an alle Studenten einer Übungsgruppe verschicken. 
		Über ein Wiki lassen sich Informationen mit den Dozenten austauschen, wie z.~B. Anwesenheitslisten.
		Damit haben Dozenten einen Überblick, welche Studenten noch an der Vorlesung teilnehmen.
		
		Dozenten können Neuigkeiten zu der Vorlesung veröffentlichen und an alle Teilnehmer
		der Vorlesung E-Mails verschicken. Studenten und Tutoren lassen
		sich zu den Übungsgruppen zuteilen. Über die Punkteübersicht können sich Dozenten jederzeit
		ein Bild über die erreichte Punktezahl der Studenten machen. 
	 	
	 	\vspace{1cm}
	 	
	 	Das CIS deckt bereits viel Administrationsarbeit ab und erleichtert so das Halten von Vorlesungen.
	 	Es gibt aber noch Optimierungspotential:
	 	
	 	Bislang muss sich ein Benutzer für jede Vorlesung erneut registrieren.
	 	So passiert es, dass Studenten vergessen sich für eine Vorlesung zu registrieren oder sich
	 	aber mehrmals für die gleiche Vorlesung anmelden. Würde man alle Vorlesungen unter einem Account
	 	zusammenzufassen, würde man diese Problematik umgehen. Zudem wäre es möglich, Stundenpläne
	 	oder eine Startseite mit aktuellen Informationen zu allen Vorlesungen zu generieren.
	 	
	 	Am Ende des Semesters bekommt jeder Student eine Note für die belegte Vorlesung. Neben dem
	 	Ergebnis aus einer Klausur fließt auch das Ergebnis der Übungsaufgaben mit in die Note ein.
	 	CIS2 bietet jedoch keine Möglichkeit, die Note automatisch berechnen zu lassen. Es fehlt überdies
	 	eine Möglichkeit, bestimmte Aufgaben für bestimmte Studenten aus der Wertung zu nehmen. So muss
	 	für alle Studenten, die mindestens einmal entschuldigt eine Aufgabe nicht abgegeben haben,
	 	das Endergebnis von Hand berechnet werden. Dies bedeutet einen
	 	erheblichen Mehraufwand für die Dozenten.
		
		Diese und weitere Schwächen des CIS2 ließ den Wunsch einer Weiterentwicklung aufkommen.
		Der Inhalt dieser Bachelorarbeit ist die Weiterentwicklung des CIS
		
		
		\vspace{1cm}	 	
	 	
	 	Kapitel 2 gibt einen Überblick über CIS2 und die Anforderungen an das CIS3. 
		In Kapitel 3 werden alle verwendeten Technologien vorgestellt und bei möglichen Alternativen 
		wird begründet,	welche vorgezogen wurde.
	 	Kapitel 4 gibt einen Überblick über die praktische Umsetzung und erläutert die einzelnen Komponenten.
	 	Anhang 1 zeigt, wie CIS3 erweitert werden kann. 



\chapter{CIS}
	Das Course Information System (CIS) ist eine Internetplattform, 
	die hilft den Administrationsaufwand einer Vorlesung gering zu halten. Es wird derzeit im Fachbereich
	Informatik an der Eberhard Karls Universität eingesetzt. Entwickelt wurde die erste Version im Jahr 2000 am
	Lehrstuhl "`Computer Algebra"' von Prof. Loos für die Informatik I/II Vorlesung. Im Jahr 2007 wurde 
	das CIS im Rahmen einer Studienarbeit von Arno Fleck weiterentwickelt. Es basiert auf PHP 5 und MySQL.
	
	In Kapitel 2.1 wird der aktuelle Funktionsumfang des CIS erläutert. Hier werden die Eigenschaften
	von CIS2 und CIS3 gegenüber gestellt. Kapitel 2.2  führt aus, warum das CIS2 erweitert werden soll.
	In Kapitel 2.3 wird abschließend
	auf die Anforderungen an das CIS3 eingegangen.
	\section{Funktionsumfang CIS}
		CIS2 ist modular aufgebaut. Jede Komponente wie etwa das Newssystem, Übungsblätter oder das Wiki
		sind in jeweils einem eigenen Modul realisiert. Dies ermöglicht es, das CIS einfach zu erweitern.
		Der Funktionsumfang des CIS ist somit die Summe seiner Module. 
		Im Folgenden werden die einzelnen Komponenten vorgestellt. Dabei wird in tabellarischer Form
		der Funktionsumfang von CIS2 und CIS3 gegenübergestellt.
		Ein Haken Bedeutet, dass die Funktion implementiert ist, ein Kreuz, dass die Funktion zwar noch
		nicht implementiert, aber geplant ist. Steht weder ein Haken oder ein Kreuz, ist das Feature
		nicht implementiert und es ist auch nicht geplant, es zu implementieren.
			
		\subsection*{News}
			Während des Haltens einer Vorlesung müssen den Studenten Neuigkeiten zugänglich gemacht werden:
			Termin und Ort von Klausuren können sich ändern, es gibt Änderungen an den Übungsaufgaben,
			Räume von Vorlesungen oder Übungsgruppen können sich ändern uvm. 
			Damit diese Informationen die Studenten erreichen, gibt es das Newssystem. Hier können Dozenten
			News erstellen, die für alle Benutzer einsehbar sind. Diese lassen sich im CIS 
			auf einer eigenen Seite oder einer statischen Seite anzeigen, oder per RSS Reader abrufen.
			Die News lassen sich in der Reihenfolge verändern, können auf inaktiv geschaltet
			oder mit einem Datum versehen werden, ab dem sie automatisch nicht mehr sichtbar sind.

			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Editierbar & \jo & \jo \\
				Reihenfolge veränderbar & \jo & \jo \\
				Gültigkeitsdatum einstellbar & \jo & \jo \\
				Wechsel zwischen aktiv/inaktiv möglich &  & \jo \\
				RSS Feed & \jo & \no
			\end{tabular}
		\subsection*{Downloads}		
			Begleitend zu Vorlesungen werden oft verschiedene Dateien den Studenten zum Download zur Verfügung
			gestellt. Je nach Vorlesung können das Programmbibliotheken für Übungsaufgaben, Vorlesungsskripte,
			Beispielcodes aus der Vorlesung oder Informationsblätter zu organisatorischen Dingen sein.
			Das CIS bietet die Möglichkeit Dateien hochzuladen und den Studenten zur Verfügung
			zu stellen. Downloads können zur besseren Übersicht in Kategorien angeordnet werden.

			\vspace{7mm}
						
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Downloads editierbar & \jo & \jo \\
				Kategorien für Downloads & \jo & \jo \\
				Externe Links einbindbar &  & \jo \\
				Sichtbarkeit einstellbar & \jo & \no
			\end{tabular}
		
		\subsection*{Benutzermails}
			Um Studenten zu informieren ist das Newssystem nicht immer der geeignete Weg. Entweder,
			weil die Information die Studenten
			kurzfristig erreichen oder nur ein bestimmter Teil der Benutzer erreicht werden soll.
			Dafür gibt es Benutzermails. Damit lassen sich E-Mails an bestimmte Benutzergruppen 
			senden, ohne dass die E-Mail Adressen von Hand eingetragen werden müssen. 
			So kann ein Dozent allen Studenten,
			allen Tutoren oder sowohl allen Studenten als auch allen Tutoren eine E-Mail schicken.
			Tutoren können zusätzlich allen Studenten ihrer Übungsgruppe eine E-Mail schicken.

			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Mails an bestimmte Benutzergruppen & \jo & \jo \\
				Archiv gesendeter Mails & \jo & \jo \\
				Mails an Einzelpersonen & & \no 
			\end{tabular}		
		\subsection*{Statische Seiten}
			Statische Seiten dienen dazu, Studenten Informationen zur Vorlesung zugänglich zu machen. 
			Hier können z.~B. Literaturtipps, Informationen zum Ablauf oder weitergehende Links 
			angeboten werden. Die statischen Seiten können von den Dozenten frei gestaltet werden. Auch gibt
			es keine Beschränkung in der Anzahl von statischen Seiten.
			News können innerhalb einer statischen Seite angezeigt werden, ebenso ist es möglich, für einen
			angemeldeten Studenten die zugehörige Übungsgruppe anzuzeigen.

			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Beliebig viele statische Seiten & \jo & \jo \\
				Statische Seiten beliebig gestaltbar &  \jo   &  \jo \\
				News lassen sich einbinden & \jo & \no \\
				Eigene Übungsgruppe lässt sich anzeigen & \jo & \no \\
				Sichtbarkeit einstellbar & & \jo \\
				Änderungen direkt auf der Seite durchführbar & & \jo \\
			\end{tabular}
		\subsection*{Übungsgruppen}
			Zu fast jeder Informatik-Vorlesung wird in Tübingen eine begleitende Übung angeboten. 
			Diese Übungen
			haben den Zweck, den Studenten das Erlernen des Vorlesungsstoffes zu erleichtern. Die Übungen
			werden von Tutoren (Studenten höheren Semesters oder Doktoranden) geleitet. In den Übungen
			wird der Stoff der Vorlesung rekapituliert, es werden Übungsaufgaben besprochen und Fragen 
			zur Vorlesung beantwortet. 
			
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Mehrere Tutoren möglich & & \jo \\
				Zeiten unabhängig von Übungsgruppen & \jo & \jo \\
				automatische Zuweisung zu Übungsgruppen & \jo & \no \\
				Mehrere Übungsgruppen getrennt behandelbar & & \jo \\
				Studenten müssen nicht an Übungsgruppen teilnehmen & & \jo \\
			\end{tabular}
		\subsection*{Übungsblätter}
			Damit die Studenten den Vorlesungsstoff zu Hause wiederholen und vertiefen, 
			werden zumeist wöchentlich Übungsblätter ausgegeben. 
			Um sicherzustellen, dass die Studenten die Übungsblätter bearbeiten, werden diese korrigiert,
			benotet und fließen in die Endnote mit ein. 

			Bei der Erstellung eines Aufgabenblattes wird das Aus- und Abgabedatum sowie die Abgabeform
			spezifizert (z.B. elektronisch, eine Zip-Datei usw.). Außerdem werden die Aufgaben
			mit Name, Punktzahl und der Option, ob es sich um eine Bonusaufgabe handelt, definiert,
			so dass die Tutoren später für die jeweiligen Studenten die Punktzahl eintragen können.

			Neben den Übungsblättern gibt es noch weitere Leistungen, die die Studenten neben der Klausur
			erbringen müssen. Dies können z.~B. Testate oder Präsenzübungen (siehe weiter unten) sein.
			Das Erreichen einer bestimmten Punktzahl in jeder dieser Kategorien ist notwendig,
			um Credit Points für eine Vorlesung zu bekommen. Um den Studenten zu zeigen, ob sie die
			Anforderungen erfüllen, müssen die verschiedenen Kategorien auch im CIS abgebildet werden.
			Deshalb kann man Kategorien erstellen und mit einer Mindestanforderung versehen. 
			Übungsblätter werden dann einer dieser Kategorien zugeordnet.

			Beim Erstellen der Übungsblätter lassen sich neben den elektronischen Abgaben auch die Aufgaben
			definieren, für die die Studenten Punkte erlangen können. Es lässt sich ein Name, die Punktzahl
			und die Option, ob es sich um eine Bonusaufgabe handelt, angeben. Für diese Aufgaben
			können die Tutoren später die Punkte eintragen.
			
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Verschiedene Kategorien erstellbar & \jo & \jo \\
				Mindestanforderungen definierbar & \jo & \jo \\
				Automatische Zuordnung zu Kategorien & & \jo \\
				Musterlösung für Tutoren möglich & \jo & \jo \\
				Gewichtung der Kategorien möglich & & \jo \\
				Punkte für Übungsaufgaben & \jo & \jo \\
				Optionale Aufgaben möglich & \jo & \jo \\
				Punkteübersicht über alle Studenten & \jo & \jo \\
				Punktzahl nach Excel exportierbar &  & \jo \\
				Statistiken möglich & & \no \\
				Status für Punktzahl (entschuldigt) & & \jo \\
				Abweichendes Datum für elektronische Abgaben & \jo & \jo \\
				Prefix für elektronische Abgaben & \jo & \jo \\
				Dateiname für elektronische Abgaben lässt sich vorgeben & \jo & \jo \\
				Nur eingetragene Punkte zur Berechnung der Anforderung einbeziehen & & \jo \\
			\end{tabular}

		\subsection*{Punkte}
			Jede Woche Punkte für jeden Studenten einzutragen bedeutet viel Arbeit. Am Ende des Semester
			muss aus der Punktzahl eine Endnote berechnet werden. Bei vielen Studenten werden einzelne
			Abgaben nicht gewertet, z.B. weil sie entschuldigt gefehlt haben. 
			Hier gibt es viele Möglichkeiten die Arbeit zu erleichtern. Geben Studenten in Gruppen ab,
			wäre es sinnvoll die Punkte pro Team nur einmal einzutragen. Die Punktzahl automatisch
			zu berechnen würde am Ende des Semester den Dozenten viel Arbeit ersparen.
			
			\vspace{7mm}
						
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline				
				Punkteübersicht über alle Studenten & \jo & \jo \\
				Punktzahl nach Excel exportierbar &  & \jo \\
				Statistiken möglich & & \no \\
				Status für Punktzahl (entschuldigt) & & \jo \\
				Nur eingetragene Punkte zur Berechnung der Anforderung einbeziehen & & \jo \\
				Abgabeteams für Studenten & & \jo \\
				Automatische Berechnung der Endnote & & \no \\
			\end{tabular}						

		\subsection*{Präsenzübungen}
			In den Vorlesungen Informatik I/II wird den Studenten beigebracht, Programme zu entwickeln.
			Dazu ist es wichtig, dass die Studenten regelmäßig selber üben. Hierzu wurden in Tübingen 
			die sogenannten Präsenzübungen eingeführt. Hier bearbeiten die Studenten in bestimmter Zeit
			Übungsaufgaben. Die Tutoren betreuen während den Präsenzübungen die Studenten, beantworten Fragen
			und geben Hilfestellung. Die Lösungen der Studenten werden über das CIS abgegeben. Die Tutoren
			korrigieren und benoten die Lösungen der Studenten.

			Damit die Präsenzübungen reibungslos ablaufen bedarf es einigen Organisationsaufwand.
			Übungsgruppentermine müssen zwischen den Tutoren koordiniert werden. Studenten müssen sich
			zu den Terminen eintragen, wobei nur eine bestimmte Anzahl an Computern für die Studenten 
			zur Verfügung steht. Es muss sichergestellt werden, dass die Studenten während den
			Präsenzübungen nicht Lösungen aus anderen Quellen abrufen können. 
			Zudem dürfen nur von den Computern aus Lösungen über das CIS hochgeladen werden, 
			an denen die Studenten tatsächlich sitzen. Die Lösungen müssen dann den Tutoren zugänglich
			gemacht werden.

			Präsenzübungen sind im CIS2 rudimentär implementiert. So können Präsenzübungstermine nur über 
			Textdateien definiert werden. Die IDs der Termine ergeben sich durch die Reihenfolge, das Entfernen
			eines Termins verschiebt die Studenten und Tutoren in eine falsche Präsenzübung.
			
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Digitale Abgaben & \jo & \no  \\
				Zuordnung der Studenten zu Rechnern & \jo & \no \\			
			\end{tabular}				

		\subsection*{Elektronische Abgaben}
			In vielen Vorlesungen sind elektronische Abgaben erwünscht. Zum einen, weil dies umweltschonend
			ist, zum anderen ist es bei Programmcode wichtig, diesen ausführen zu können. Zudem ist damit
			eine Plagiatsüberprüfung möglich. 
		
			Um dies zu ermöglichen, können Studenten ihre elektronischen Lösungen über das CIS hochladen.
			Die Tutoren können dann die Lösungen ihrer Übungsgruppe gesammelt 
			herunterladen. Braucht man aber nur eine bestimmte Lösung, lassen sich
			die Lösungen nach bestimmten Kriterien durchsuchen und die einzeln herunterladen.
			Sollte ein Student vergessen haben eine Lösung abzugeben, lässt sich die Lösung
			über ein Formular nachreichen.
			
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Studenten können Abgaben hochladen & \jo & \jo \\
				Tutoren und Dozenten können Abgaben herunterladen & \jo & \jo \\
				Browsen durch Abgaben & \jo & \jo \\
				Nachreichen von Abgaben & \jo & \jo \\
				Plagiatsüberprüfung & \jo & \no 
			\end{tabular}			
							
		\subsection*{Wiki}
			In den Anfängervorlesungen mit über 200 Studenten werden viele Tutoren beschäftigt, 
			(in der Informatik I im WS2010/11 waren es 16). Dadurch entfällt ein Teil der Administrationsarbeit 
			auf die Koordinierung der Tutoren und dem Informationsaustausch zwischen Dozenten und Tutoren. 
			Die Dozenten müssen etwa über den Fortschritt der Studenten oder der Anzahl der Studenten, die die
			Übung weiterhin besuchen, auf dem Laufenden gehalten werden. Um den Stoff in den Übungsgruppen
			zu vertiefen bietet es sich an den Tutoren weitere Beispielaufgaben
			oder für Tests Fragen zu Verfügung zu stellen.

			Um diesen Informationsaustausch zu erleichtern, ist in das CIS ein Wiki eingebaut. 
			Die Dozenten können hier neue Seiten erstellen, die auch von den Tutoren bearbeitet
			werden können. Tutoren können dann z.~B. Anwesenheitslisten führen und 
			Einschätzungen zu ihren Studenten verfassen.			
			
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Beliebig viele Seiten erstellbar & \jo & \no \\
				Sichtbarkeit einstellbar & \jo & \no \\
				Integrierte Anwesenheitslisten & & \no \\
			\end{tabular}			
			
		\subsection*{Studententeams}
			Um Vorlesungsinhalte praktisch zu vertiefen, werden oft auch Praktika angeboten. Exemplarisch seien
			hier die Anforderungen der Veranstaltung "`Software Engineering"' genannt. Diese Veranstaltung
			besteht aus einer Vorlesung und einem begleitenden Projektpraktikum. In der Vorlesung werden
			den Studenten viele Themen rund um Softwareentwicklung vermittelt. Begleitend dazu entwickeln 
			die Studenten in kleinen Gruppen Softwareprojekte, etwa Netzwerkspiele, Steuerung von Robotern oder
			Compiler. Die Studententeams werden von Mitarbeitern der Lehrstühle betreut.

			Um die Organisation dieser Studententeams zu erleichtern, lassen sich im CIS
			Studententeams einrichten. Für diese Teams lässt sich ein SVN Server einrichten.
			Für jedes Teammitglied lässt sich ein Account auf diesem SVN Server einrichten.						
			\vspace{7mm}
			
			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Studententeams & \jo & \no \\
				SVN Server Studententeams & \jo & \no \\
				Weitere Versionverwaltung (Mercurial etc.) & & \no \\
				Automatische Passwortübernahme & & \no \\
				Trac & & \no \\
			\end{tabular}
			
		\subsection*{Spezialfunktionen}
		

			\begin{tabular}{|l|c|c|}
				Funktionen & CIS2 & CIS3 \\ \hline
				Forum integrieren & & \no \\
				Externe HTML Seiten integrieren & & \no \\
				Tauschbörse für Übungsgruppen & & \no \\
			\end{tabular}
			
		\subsection*{Weitere Funktionen}
			Über die genannten Funktionen hinaus gibt es weitere Wünsche, die jedoch bisher noch nicht
			implementiert sind.
			
			Um das Ausstellen von Prüfungsleistungen zu erleichtern, wäre eine Funktion wünschenswert,
			die einen entsprechenden Ausdruck mit Hilfe der im CIS gespeicherten Daten generiert

			Oft werden Punkte, z.~B. für Klausuren, in einer Excel Tabelle gesammelt. Könnte man
			so eine Excel Tabelle direkt in das CIS importieren, hätte man sich sehr viel Arbeit gespart.

			Ein Startbildschirm, auf dem die wichtigsten News gesammelt werden, würde viel Arbeit sparen.
			Man würde z.B. direkt sehen, ob ein Tutor schon Punkte eingetragen hat, ob ein neues Übungsblatt
			erschienen ist oder bekäme eine Erinnerung, dass noch eine Abgabe fehlt.
			
			Nützlich wäre es, wenn man Vorlesungen archivieren könnte. Vorlesungen würden dann in einer
			auf das wesentliche reduzierten Version im CIS hinterlegt. Auf diese Informationen könnte
			man dann jederzeit zurückgreifen, die Vorlesungen wären aber klar von noch aktiven Vorlesungen
			getrennt. 			
		
	\section{Schwächen des CIS2}
	 	
	 	Schon bei der ersten Benutzung des CIS fällt auf, dass für jede zu belegende Veranstaltung eine erneute
	 	Registrierung notwendig ist. So kann es vorkommen, dass ein Student sich pro Semester mehrere male
	 	registrieren muss. 
	 	
	 	Ein weiteres Defizit wird beim Eintragen von Punkten offensichtlicht. Es ist hierbei nicht möglich zu
	 	spezifizieren, ob Punkte gewertet werden. Dies verhindert, dass Noten automatisch berechnet werden können. 
	 	So muss für eine Veranstaltung
	 	zumeist die Punktzahl aus dem CIS exportiert, korrigiert und wieder eingetragen werden.
		Oft reichen Studenten ihre Lösungen in zweier oder dreier Teams ein. Im CIS muss die Punktzahl
	 	für jeden Student einzeln eingetragen werden.
	 	
	 	Im Gespräch mit Dozenten, Übungsleitern und Tutoren wurden viele, oft sehr kleine, Funktionen erwähnt,
	 	die den Alltag deutlich erleichtern würden. 
	 	
	 	In Präsenzübungen muss ein Student, nachdem er zu einem Computer zugeteilt wurde, freigeschaltet werden.
	 	Es gibt aber keine Möglichkeit um alle Studenten auf einmal freizuschalten. 
	 	
	 	Im Wiki werden Anwesenheitslisten der Übungsgruppen geführt. Ein Template für Anwesenheitslisten würde die Arbeit abnehmen,
	 	diese jedes Mal von Hand per HTML zu erstellen.
	 	
	 	
	 \section{Anforderungen an CIS3}
	 	Idealerweise werden alle Vorlesungen über das gleiche System verwaltet. Derzeit ist das nicht
	 	der Fall, mehrere Lehrstühle bieten ein eigenes System an. Der Lehrstuhl "`Kognitive Systeme"' 
	 	veröffentlicht Übungsblätter auf der eigenen Seite, ebenso die Lehrstühle des GRIS 
	 	\footnote{GRIS steht für Graphisch-Interaktive Systeme. Es handelt sich hier um die Lehrstühle
	 	der Medieninformatik}. 
	 	Mehr als Übungsblätter und ein paar Informationen findet sich auf diesen Seiten jedoch nicht. 
	 	So ist etwa	die Einsicht der Punkte für die Übungsblätter nicht online möglich. Das verringert aus
	 	Sicht der Studenten die Transparenz, der aktuelle Stand lässt sich nicht jederzeit ermitteln.
	 	Durch verschiedene Anlaufstellen ergibt sich eine große Zersplitterung,
	 	die sich besonders für die Studenten negativ auswirkt. Es wäre ein großer Erfolg,
	 	wenn das CIS von allen Lehrstühlen verwendet werden würde. 

	 	Es ist daher wichtig, dass die Bedienung einfach und intuitiv gestaltet wird, so dass selbst
	 	unbedarfte Benutzer damit sofort zurechtkommen. Es sollte sich im Aufbau an das alte CIS orientieren,
	 	damit ein Umstieg möglichst einfach ist.
	 	Es sollte sowohl für große als auch für kleine Vorlesungen sinnvoll einsetzbar sein und 
	 	Werkzeuge zur Administration anbieten.

	 	Sicherheit und Datenschutz ist eine Grundvoraussetzung für das CIS, da mit
	 	sensiblen Daten hantiert wird: Daten wie Name, E-Mail Adresse, Matrikelnummer, Passwörter, Noten uvm.
	 	dürfen auf keinen Fall öffentlich zugänglich sein.
	 	Es ist daher unabdingbar, dass der Schutz der Daten in dem System garantiert wird.

	 	Anforderungen an ein System, das begleitend zu einer Vorlesung eingesetzt wird, können sich mit
	 	der Zeit ändern, so dass eine Modifikation des System notwendig werden kann. Mit der Zeit kommen
	 	Wünsche für weitere Funktionen oder Änderungen auf.
	 	Es ist daher wichtig, dass die Architektur des CIS modular ist und sich so möglichst einfach
	 	erweitern lässt. Dazu ist es unerlässlich, dass alle Komponenten gut dokumentiert sind,
	 	der Programmcode verständlich und alle Methoden und Felder ausreichend kommentiert sind. 
	 			
\chapter{Technologien}		
	Bei Softwareprojekten im Allgemeinen und Java EE Projekten im Besonderen ist die Wahl der eingesetzten
	Technologien essentiell. Für viele Problemstellungen existieren bereits Frameworks oder Bibliotheken, 
	die einem viel Arbeit abnehmen und so die Entwicklung der Software beschleunigen. Es existieren
	sogar meist für die gleichen Problemstellungen verschiedene Softwarelösungen, die jeweils Vor-
	und Nachteile besitzen. Es ist daher wichtig, für die Software die geeignetste Lösung auszusuchen.
	Wichtige Faktoren sind Kosten, Lizenzart, Verbreitung der Technologie, Güte der Dokumentation und
	nicht zuletzt technische Faktoren wie Funktionsumfang und technische Ausgereiftheit. 
	Ein entscheidender Teil dieser Bachelorarbeit war es daher, bestimmte Technologien zu sichten,
	zu bewerten und auszuwählen. Grundvorraussetzung war, dass die eingesetzten Technologien allesamt
	kostenlos, idealerweise Open Source, sind.
		
	Da es sich beim CIS3 um eine Webanwendung handelt, werden verschiedene Softwarelösungen benötigt.
	Es wird eine Serversoftware benötigt. In diesem Projekt kommt GlassFish zum Einsatz, ein Java EE
	Application Server. ICEfaces, ein Webframework, kommt als Grundlage für die eigentliche Programmierung
	zum Einsatz. Für die Datenanbindung wird Hibernate genutzt. Facelets sind eine Templating Technologie,
	um die Ansicht einheitlich zu gestalten und Programmcode wiedezuverwenden.
	Java Mail ermöglicht den Mailversand.
	Das Zusammenspiel wird in Abbildung 3.3 dargestellt. 

	GlassFish bildet die Grundlage, führt die Anwendung aus und handelt später alle Anfragen. 
	ICEfaces ist das Kernframework für das CIS, in dem die Programmlogik angesiedelt ist,
	die Daten entsprechend verarbeitet und die gewünschte Ansicht generiert wird. 
	Zudem werden dort weitere Komponenten wie etwa Java Mail für die E-Mail Kommunikation 
	oder Hibernate gesteuert.

	Für die Datenbankanbindung wird Hibernate verwendet. Hibernate ist ein Persistenz und Object-Relation-
	Mapping-Framework.
	Die interne Verschlüsselung basiert auf Apache Commons, als Verschlüsselungsalgorithmus wird SHA-512 
	verwendet.

	Zusammen bilden diese Technologien die Grundlage für das CIS3.
	\begin{figure}[hbt]
		\centering
		\includegraphics[scale=0.4]{technologien.png} 
		\caption{Zusammenspiel der Technologien}
	\end{figure}

	Im Folgenden werden die verschiedenen Technologien vorgestellt und bewertet.
	\section{ICEfaces}
		\subsection{Überblick}
			Java Server Pages (JSP) wurde eingeführt, um mit Hilfe von Java dynamische Webseiten zu 
			entwickeln. Darauf aufbauend wurde Java Server Faces eingeführt. Mit JSF können graphische
			Benutzeroberflächen für Webapplikationen entwickelt werden.
			ICEfaces ist eine Erweiterung zu JSF, es handelt sich hierbei um Framework,
			das JSF um AJAX Funktionalität erweitert.
			Für die Java EE Technologien wie JSP oder JSF wurde die Unified Expression Language (EL),
			eine Skriptsprache, eingeführt.
			Im Folgenden werden die einzelnen Komponenten erklärt und anschließend wird 
			auf das Framework ICEfaces selber eingegangen.
		\subsection{Facelets}
			Eine Webseite ist typischerweise in verschiedene Bereiche unterteilt. Beim CIS befindet sich
			oben einen Banner, darunter befindet sich das Menü und darunter den Inhalt
			der jeweiligen Seite. Dieser Aufbau soll auf jeder Seite gleich sein, damit das Design
			der Seite einheitlich erscheint. Es ist zudem nicht notwendig, dass z. B. der Banner
			bei jedem Seitenaufruf neu geladen wird, da er sich nicht verändert.
			Um das zu bewerkstelligen, wird bei der Erstellung von Webseiten auf Templating zurückgegriffen.
			Die Templating Technologie für JSF ist Facelets. Mit Facelets lassen sich Vorlagen definieren,
			die von anderen Seiten verwendet werden. Die Vorlage kann auch bestimmte Bereiche fest vorgeben,
			andere dagegen variabel lassen. Die Vorlagen können auch verschachtelt werden.
			
			
		\subsection{Unified Expression Language}
			Die Unified Expression Language (EL) ist eine, im Funktionsumfang stark begrenzte, Skriptsprache.
			Sie ermöglicht es, die Verbindung zwischen Ansicht, Logik und 
			Daten herzustellen. So können Werte von Objekten an Komponenten 
			gebunden und Listener für Komponenten registriert werden.
			
			In der unified EL hat man nur Zugriff auf die \emph{Managed Beans}. 
			Bei Managed Beans handelt es sich  um Klassen, die (ähnlich zu Java Beans) 
			zwei Vorraussetzungen erfüllen müssen: 
			Sie müssen zum einen einen Konstruktor ohne Parameter besitzen. Zum anderen 
			müssen Felder private deklariert sein und die zugehörigen Zugriffsmethoden der Form getFeld 
			und setFeld besitzen. 
			
			\footnote{Bei boolschen Werten ist als Getter
			auch isFeld möglich}. 
			Der Unterschied zwischen Managed Beans und Java Beans ist, dass Java Beans zusätzlich 
			das serializable Interface implementieren müssen.
			\footnote{Das serializable Interfaces fordert keine Methoden, 
			die Implementierung entspricht dem Setzen
			eines Flags. Damit wird signalisiert, dass ein Objekt und alle seine Komponenten 
			serialisierbar sind. Dies ist erforderlich bei jeglicher Art von Datenübertragung.} 
			implementieren.
			
			Die Registrierung von Managed Beans erfolgt entweder per XML Definition oder per Annotation.
			Nun werden die Managed Beans durch JSF verwaltet. Dabei muss zusätzlich noch ein Scope 
			angegeben werden, der angibt, wie lange das Objekt vorgehalten wird.
			Die wichtigsten sind:
			\begin{itemize}
				\item Application Scoped: Die Managed Bean exisitert solange die Anwendung läuft.
				\item Session Scoped: Die Managed Bean existiert solange die Session des Benutzers aktiv ist.
				\item View Scoped: Die Managed Bean existiert solange die Ansicht existiert, 
						also bis die Seite neu geladen wird oder auf eine andere Seite weitergeleitet wird.
				\item Window Scoped: Window Scoped ist ein ICEfaces spezifischer Scope. 
						Er liegt zwischen Session Scoped und View Scoped: Die Managed Bean exisitert solange, 
						bis das Browser Fenster geschlossen wird. Es hält also länger als View Scoped, 
						aber es lassen sich mehrere Instanzen in verschiedenen Browserfenstern erstellen.
				\item Request Scoped: Die Managed Bean existiert, bis ein Request an den Server gesendet wird.
			\end{itemize}
				
			Angekündigt wird die unified EL in JSF durch ein \#, der Code selber wird von geschweiften Klammern umgeben.
			Wie in Java selber greift man auf Felder und Methoden mit einem Punkt zu. Will man also den Wert eines Eingabefeldes
			an das Feld "`name"' im Managed Bean "`objekt"' binden, so schreibt man
			\# \{ objekt.name\}.
			Der Zugriff erfolgt über die Getter- und Settermethoden.
			Zusätzlich hat man in der unified EL Zugriff auf ein paar arithmetische und boolesche Operatoren
			und kann Werte auf \textit{null} prüfen. 
					
		
		\subsection{Java Server Pages}
			
			Java Server Pages (JSP) ermöglicht es, Java Code direkt in eine HTML Seite einzubinden. 
			Dies funktioniert ähnlich wie bei PHP. Alles, was innerhalb der Tags \verb+<%@ und %>+ 
			steht, wird als Java Code interpretiert und ausgeführt. Außerdem gibt es einige Schlüsselwörter 
			für bestimmte Aktionen, z.~B. importiert \verb+<%@ page import java.util.* %>+ 
			auf der Seite alle Java Util Bibliotheken. Mit JSP kann man dynamische Seiten entwickeln, 
			dank Java unterliegt man fast keiner Beschränkung. 
			Während JSP 1.0 keine strikte Trennung zwischen Logik und Ansicht vorsah und daraus
			schnell unübersichtliche Seiten resultierten, wurde mit JSP 2.0 Abhilfe für dieses
			Problem geschaffen: Anstatt den Code in eine HTML Datei zu integrieren,
			werden XML Dateien erzeugt, 
			in der Tags aus der Java Server Tag Libray (JSTL) verwendet werden. 
			Zusammen mit der unified EL wird 
			die Verwendung von Java Code in der XML Datei überflüssig gemacht und auf externe Klassen auslagert.
			So wird man mit JSP 2.0 erstmals das MVC Pattern umgesetzt.
		
		\subsection{Java Server Faces}
			
			Das Ziel von Java Server Faces (JSF) ist, die Entwicklung einer Web Anwendung ähnlich 
			zu gestalten wie die Entwicklung einer Desktop Anwendung. 
			JSF ist ein Bestandteil der Java EE Spezifikation.
			Java EE orientiert sich stark an der Ansprüchen der Industrie. Verfügbarkeit von Programmierern
			ist ein wichtiger Faktor für oder gegen eine Entwicklungsplattform. Durch die Anlehnung
			der Architektur von Web Anwendung an die Architektur von Desktop Anwendungen wird dieses 
			Ziel erreicht, da Entwickler von Desktop Anwendungen auch für Web Anwendungen herangezogen
			werden können.

			Ein weiteres Augenmerk, wie schon bei JSP 2.0, liegt auf der strikten Trennung der Ansicht
			vom Rest des Codes. Mit den Mitteln von JSF ist es nicht möglich, 
			mehr Logik in eine Ansicht einzubauen, als die unified EL zur Verfügung stellt. Hierzu
			ist ein Rückgriff auf JSP notwendig.

			In JSF wird der Ablauf eines Programmes über Events gesteuert. 
			JSF Anwendungen unterliegen einem Lebenszyklus, der in sechs Phasen aufgeteilt ist. 
			Diese Phasen beschreiben dabei den Ablauf von Aufbau der Seite über die 
			Verarbeitung von Eingaben bis zum erneuten Aufbau der Seite.
			\begin{enumerate}
				\item \emph{Restore View:} Hier wird die Seite erzeugt, sowie der 
							Faces Kontext aktualisiert. Der Faces Kontext speichert alle relevanten
							Informationen der Seite.
							Zu dem Faces Kontext hat man überall Zugriff, insbesondere in den Event Listenern.
				
				\item \emph{Apply Requests:} Die Werte aus dem Request
							werden den Komponenten lokal zugewiesen. Wichtig: Value Change Listener werden schon
							aufgerufen, die Werte in den Objekten werden aber erst in der Update Model Values 
							Phase geändert.
							Es lassen sich also in Value Change Listener neue Werte nicht aus dem Model abrufen,
							sondern nur durch das übergebene Event.
							Falls nötig werden die Werte zudem konvertiert: 
							Wenn z.~B. der Wert eines Eingabefeldes an ein Integer Wert in einem Objekt 
							gebunden ist, so wird die Eingabe von String zu Integer konvertiert.
							Nach diesem Schritt werden die registrierten Value Change Listener aufgerufen.
				\item \emph{Process Validations:}
							In dieser Phase werden alle registrierten Validitatoren ausgeführt. Mit Hilfe von Validitatoren
							lässt sich z.~B. der Wertebereich für Eingaben begrenzen. Sollte eine Validitation fehlschlagen,
							wird der Lebenszyklus bis zur Render Response Phase übersprungen.
				\item \emph{Update Model Values:}
							Hier werden den Feldern in den Managed Beans die Werte der 
							zugehörigen Komponenten zugewiesen. Sollten Konvertierungsfehler
							auftreten, wird ein Fehler ausgegeben und die Invoke Application Phase übersprungen.					\item \emph{Invoke Application:} 
							Hier werden Eingaben einer Form behandelt. Wird eine Form abgeschickt,
							löst dies Action Events auf. In Folge dessen werden ActionListener und Action 
							Methoden aufgerufen. Diese werden benötigt, wenn eine Aktion stattfinden soll,
							wie das löschen eines Elementes oder die Weiterleitung auf eine andere Seite.
							
							Action Listener erhalten das
							Event, das das Auslösen der Phase verursacht hat. Action Methoden dagegen 
							werden verwendet, wenn eine Navigation stattfinden soll.
							\footnote{Navigation kann auch in XML Dateien definiert werden. Praktischer
							ist allerdings die hier verwendete Methode über Action Methoden}
							Dazu geben sie einen String zurück, der die nächste Seite angibt.
							\footnote{Die Endung der Seite muss von XHTML auf jsf geändert wird. Dies ist
							wichtig, da nicht auf die XHTML Seite selber, sondern auf die daraus generierte
							Seite verlinkt werden soll.}
							Mit JSF 2.0 können Action Methoden auch den Rückgabetyp void haben. 
							Sinnvoll ist dies, wenn man mit parametrisierten Methodenaufrufen arbeitet. 
							Bei void Methoden findet keine Navigation statt. 
							
							Wenn eine Navigation stattfindet, wird Response Complete aufgerufen und 
							der Lebenszyklus beginnt für die neue Seite von vorn.
				\item \emph{Render Response:}
							In dieser Phase findet das Rendern der Seite statt.				
			\end{enumerate}
			\newpage
			\begin{figure}[htb]
				\centering
				\includegraphics[scale=0.6]{jsfintro-lifecycle.png} 
				\caption{Lifecycle einer JSF Seite \cite{jsfPhases}}
			\end{figure}
			Beim ersten Seitenaufruf werden nur die ersten zwei Phasen durchlaufen.
			Definiert werden die Seiten durch XHTML. Später generiert der Server aus diesen
			XHTML-Dateien die angeforderten Seiten, daher wird beim Aufruf der URL als Endung 
			.jsf statt .xhtml angegeben.
			\footnote{Die Standardendung ist .jsf, andere Endungen können in der Datei 
			web.xml festgelegt werden}

			JSF liefert viele Komponenten mit, die für meisten Anwendungen ausreichen. Darüber
			hinaus ist es möglich die umfangreiche Bibliothek an Komponenten um selbstgeschriebene 
			Komponenten zu erweitern.

			Die Verbindung zwischen Ansicht und Programm erfolgt wie bei bei JSP über die 
			unified EL,	mit dessen Hilfe Werte und Methoden an die Komponenten gebunden werden können.
			Einzig durch die Verwendung von primitiven Operatoren wie ! oder + lässt sich etwas Logik 
			direkt in eine Seite einbauen. 
			\footnote{Dies sollte man aber auf ein Minimum reduzieren, um das MVC Pattern nicht zu verletzen}
		
		\subsection{ICEfaces}
			
			ICEfaces ist ein Framework zur Entwicklung von Rich Internet Applications (RIA).
			Es basiert auf JSF und erweitert dies vor allem um eingebaute Ajax Funktionen.
			ICEfaces liegt zurzeit in der Version 2.0.2. vor und basiert auf JSF 2.0.
			Es gibt zwei Versionen: Eine Open Source Version und eine sogenannte EE Version.
			Die EE Version ist kostenpflichtig, dafür erhält man Support und erweiterte Komponenten.

			Aufgrund der Integration von AJAX in ICEface muss man nicht auf JavaScript zurückzugreifen,
			um eine Anwendung mit AJAX Unterstützung umzusetzen. So gibt es für jede Komponente die Attribute
			\emph{immediate} und \emph{partialSubmit}.
			Immediate sorgt dafür, dass Events, Validierung und Konvertierung bereits in der 
			Apply Request Phase verarbeitet werden (siehe Abbildung 3.2). 
			PartialSubmit sorgt dafür, dass bei einer Wertänderung die entsprechende Komponente einen Request an den Server sendet.
			Setzt man diese Attribute auf true, werde nur Daten der Komponente gesendet werden, 
			im Vergleich zu einem CommandButton, der das ganze Formular abschicken würde.
			Aus Sicht des Benutzer ensteht so eine viel größere Interaktivität, 
			da Änderungen sofort übernommen und verarbeitet werden.
			
			Da ICEfaces ein hohe Verbreitung hat (im offiziellen Forum sind etwa 150.000 User 
			registriert \cite{ICEfacesUsage}), gibt es eine große Anzahl an Hilfen, 
			wie Tutorials oder auch Forendiskussionen.
			
	
	
		\section{Datenbank}
		Damit die Daten persistent gespeichert werden, braucht man eine Art von Datenbank.
		Bisher wurde für das CIS eine relationale Datenbank verwendet. 
		Die Entscheidung lag darin, weiterhin eine Relationale Datenbank oder stattdessen
		ein Content Repository eingesetzt wird.
		Im folgenden Kapitel werden die Vor- und Nachteile abgewägt und die Entscheidung für Relationale Datenbanken begründet.
		\subsection{Content Repository/Apache Jackrabbit}
			Content Repository bezeichnet im Allgemeinen die Speicherung von digitalem Inhalt, auf den es Lese- und Schreibzugriff sowie Suchmöglichkeit gibt.
			Im hier gebrauchten engeren Sinne bezieht es sich auf Java Content Repository (JCR).  JCR ist eine Java API Spezifikation, die es ermöglicht
			auf ein Content Repository einheitlich zuzugreifen. 
			JCR basiert auf Workspaces, Nodes und Properties. Ein Repository besitzt mindestens einen 
			Workspace, Workspaces wiederum mindestens eine Node.
			Eine Node wiederum kann weitere Nodes und beliebig viele Properties enthalten.
			Properties sind entweder primitive Typen wie String, Integer oder Binarys. 
			Content Repository bilden also eine Baumstruktur ab.
			Content Repositorys sind sehr flexibel, da sie sich Aufgrund ihrer Architektur jederzeit 
			erweitern lassen.
			Durch ihre Baumstruktur sind sie näher an objekt-orientierter Architektur als 
			bspw. relationale Datenbanken.

			Apache Jackrabbit ist die Referenzimplementierung von JCR. Es liegt zur Zeit in der Version 2.2.7.
			vor und ist ein Apache Top Level Project.
			Andere brauchbare Open Source Implementierungen existieren für JCR derzeit nicht. 
			Jackrabbit unterstützt außerdem Object Content Mapping (OCM). Mit OCM kann man mit Hilfe von ein paar Annotations ganze Objekte
			in ein Content Repository mappen.
			
			Bei der Entscheidung für oder gegen Content Repository ging es darum eine Plattform zu finden, 
			die das entwickelte Datenmodell abbildet, was mit Jackrabbit umsetzbar erschien.			
			Die Dokumentation von Jackrabbit ist allerdings unvollständig. Die Webseite ist veraltet und 
			OCM scheint nicht mehr vollständig unterstützt zu werden.
			Eine Notiz dazu findet sich zwar nicht, jedoch ist OCM schon länger nicht mehr Bestandteil 
			der Releasebundles. So sind auch die Anleitungen zu OCM
			unvollständig und veraltet. Es ist daher vermutlich nicht möglich Collections vernünftig zu mappen.

			Ein weiteres Problem zeigte sich direkt nach Einbinden der benötigten Libarys. 
			Sofort schnellte die benötigte Zeit zum Deployen von max. 1 Minute auf bis über 20 Minuten.
			Dieses Phänomen verschwand, sobald die Libarys nicht mehr in das Projekt eingebunden waren. 
			
			Content Repositorys sind prinzipiell ein moderner und sinnvoller Ansatz, 
			jedoch noch nicht vollständig ausgereift. Mit den bisherigen Möglichkeiten ist es strikt
			erforderlich, sie von Anfang an in den Entwicklungszyklus einzubinden. 
			Ein nachträgliches Einbinden ist aufwändig, weil das Mappen von Objekten von Hand geschehen muss.
			Daher wurde von JCR für dieses Projekt abgesehen.
						
			
		\subsection{Relationale Datenbank/Hibernate}
			Für persistente Datenhaltung wird meist eine relationale Datenbank verwendet. Es handelt sich dabei
			um eine weit verbreitete und ausgereifte Technologie, die schnell und einfach ist. 
			Das Prinzip der Relationalen Datenbanken und Objektorientierung läuft aber zum Teil zuwider, 
			nativ lassen sich Objekte und Datenbankmodelle nicht verbinden. Es ist nötig ein
			Objekt in ein relationales Datenmodell zu überführen. Dies wird als Object Relational Mapping (ORM)
			bezeichnet. Hierbei werden Objekte auf Tabellen abgebildet und 
			Referenzen auf andere Objekte werden durch Fremdschlüssel-Primärschlüsselbeziehungen dargestellt.

			Dies wäre von Hand aufwändig, mit Frameworks wie Hibernate für Java ist dies aber gut möglich.
			Neben Hibernate gibt es ORM Frameworks wie Apache Cayenne oder ORMlite. 
			Jedoch ist keines dieser Frameworks gleichzeitig so mächtig, verbreitet und ausgereift. 
			Und trotz der Mächtigkeit von Hibernate ist es relativ einfach zu bedienen. 
			Dank Annotationen lässt sich das Mapping schnell bewerkstelligen. 
			
			Durch die Verwendung von ORM erlangt man also die Unabhängigkeit von einem konkreten 
			Datenbankmodell.
			Um das Datenmodell zu tauschen, muss allein die Konfigurationsdatei modifiziert werden.

			Ein weiteres Feature von Hibernate ist \emph{Lazy Loading}. Verwendet man Java Collections, 
			einem Datensatz in der Datenbank entsprechen, wird nicht der gesamte Datensatz auf einmal geladen,
			sondern nur das jeweilige Element, auf das man gerade zugreift.
			Hibernate liegt zur Zeit in der Version 3.6.6. vor. 
	
	\section{Server}
	
		\subsection{Einführung}
			Um CIS3 zu starten, benötigt man eine passende Serversoftware.
			Da CIS3 nur auf JSF bzw. ICEfaces aufbaut und keine weiteren Java EE Features benötigt,
			reicht ein Servlet-Container aus. Als Servlet-Container werden Java Klassen bezeichnet,
			die das Servlet Interface implementieren. Sie repräsentieren die Web Komponente in der Java EE
			Architektur. Der Servlet Container handelt alle Anfragen und generiert die Webseiten.
			\begin{figure}[hbt]
				\centering
				\includegraphics[scale=0.55]{servlet2.png} 
				\caption{Request Handling von Servlets}
			\end{figure} 
			Natürlich können auch vollständige Java EE Application Server benutzt werden.
			Application	Server bauen immer auf einen Servlet Container auf und erweitern diesen um weitere 
			Eigenschaften.
			Als reiner Servlet-Container ist Apache Tomcat am verbreitesten, es gibt aber auch Alternativen wie Jetty oder Resin.
			Als vollständigen Application Server gibt es GlassFish, Apache Geronimo, RedHat JBoss oder WebSphere. 
			Für das Projekt wurden Tomcat als Vertreter für einen schlanken Servlet-Container und 
			GlassFish als Vertreter für Application Server betrachtet.
			Für Tomcat sprach, dass es schon für CIS2 verwendet wird.
			Allgemein spricht für einen reinen Servlet-Container die bessere Performance.
			Der Vorteil von einem vollständigen Application Server ist der größere Funktionsumfang. Sollte das CIS
			später erweitert werden, wäre sichergestellt, dass kein Umzug auf einen anderen Server stattfinden muss.
			
		\subsection{Apache Tomcat}
			
			Tomcat 
			\footnote{Der Name Tomcat geht auf James Duncon Davidson zurück, der Entwickler des Vorläufers von Tomcat.
			Er hoffte, dass es ein O'Reilly Buch zum Tomcat geben würde - so wie zu vielen anderen Open Source Projekten.
			Die Buchcover von O'Reilly werden oft mit Tieren geschmückt. Daher gab er der Software den Namen 
			Tomcat (englisch für Kater), in der Hoffnung dass ein Kater das Cover ziere.  
			Leider war der Kater schon vergeben. Stattdessen zierte später ein Schneeleopard das Cover\cite{Brittain2003}}			
			ging aus einer Servlet Referenzimplementierung hervor und wurde dann in ein Open Source Projekt überführt.
			Es zählt somit zu den ältesten Servlet Containern und ist daher sehr ausgereift. In der aktuellen Version
			7.0.19. implementiert es die Servlet 3.0 Spezifikationen, JSP 2.2, JSF 2.0 und EL 2.2.
			Einer der großen Vorteile ergibt sich aus der weiten Verbreitung von Tomcat: Er ist gut
			dokumentiert, wird gut unterstützt und lässt sich dank Plugins sehr gut in 
			Entwicklungswerkzege einbinden.
			Es wird auch von einigen Application Server verwendet, z.~B. baut Apache Gironimo auf Tomcat auf.
			Neue Spezifikationen werden einigermaßen schnell eingebaut, jedoch nicht immer vollständig:
			Eine große Neuerung von EL 2.2 war es, parametrisierte Methodenaufrufe
			zu unterstützen. Dies ermöglicht elegantere und kürzere Lösungen von Problemen,
			wie etwa das Löschen von Elementen aus einer Tabelle. Version 7.0.11 
			(zu Beginn der Arbeit die aktuelle Version) sollte laut Spezifikation alle Java EE 6 Features
			vollständig umsetzen, zu denen auch EL 2.2 gehört. Parametrisierte Methodenaufrufe waren
			aber dennoch nicht möglich. \footnote{In der aktuellen Version 7.0.20 werden parametrisierte 
			Aufrufe von Methoden unterstützt}
			
			Neben Tomcat sind Jetty und Resin nennenswerte Vertreter von Servlet-Containern.
			Jetty hat eine je nach Anwendungsfall eine etwas bessere oder etwas schlechtere Geschwindigkeit
			wie Tomcat. Viele bekannte Projekte wie etwa Geronimo oder JBoss sind bereits auf Jetty umgestiegen.
			Resin gibt es in einer Open Source und einer kostenpflichtigen Version. 
			Die Open Source Variante ist deutlich abgespeckt und fällt dadurch hinter Tomcat zurück.
			
			Für Tomcat spricht die größere Verbeitung und dass das CIS2 bereits auf Tomcat zurückgreift.
			Daher fällt die Wahl auf Tomcat.
			
		\subsection{GlassFish}
			
			GlassFish ist ein vollständiger Java EE Application Server.
			Es implementiert somit die komplette Java API, also bspw. JavaMail. 
			GlassFish wird von Oracle als Referenzimplementierung von Java EE entwickelt. 
			Es liegt derzeit in der Version 3.1.1. vor und unterstützt Servlet 3.0, JSP 2.2, JSF 2.0 
			und EL 2.2. Neben der Open Source Variante gibt es einen kostenpflichtigen Server,
			hier zahlt man jedoch nur für den Support.
			Der große Vorteil von GlassFish ist die schnelle Implementierung neuer Eigenschaften. 
			Hier fällt JBoss stark ab, in der aktuellen Version 7 unterstützt es nur Servlet 2.5, 
			JSF 1.2 und JSP 2.1.
			Seit GlassFish 2.x wird dieses auf Geschwindigkeit getrimmt und ist seitdem schneller als andere
			Application Server. Zusammen mit der exakten Umsetzung der Java EE Spezifikation und einer 
			guten Integration in Netbeans und Eclipse ist es somit die erste Wahl unter den Application Servern.
			
			Der Geschwindigkeitsvorteil von Tomcat zu GlassFish ist seit der Version 2.0 minimal. GlassFish
			besitzt dafür einen größeren Funktionsumfang. So lässt sich z.~B. die Konfiguration des
			Mailservers aus dem Code auslagern.
			Die Wahl fiel somit auf GlassFish.

	\section{JavaMail}
			
			Einer der Eigenschaften von CIS ist ein Webinterface, um E-Mails an bestimmte Benutzergruppen
			zu verschicken. 
			Hierfür bedarf es der Möglichkeit mit Java E-Mails zu versenden. Dies bietet
			das Paket javax.mail. In Java EE ist dieses Paket integriert.

			Mit Hilfe von JavaMail ist das Versenden ohne interne Kenntnisse des SMTP Protokolls möglich, 
			wie folgendes Beispiel illustriert:
\begin{lstlisting}
    Properties props = new Properties();
    props.put("mail.smtp.host", "my-mail-server");
    props.put("mail.from", "me@example.com");
    Session session = Session.getInstance(props, null);

    try {
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom();
        msg.setRecipients(Message.RecipientType.TO,
                          "you@example.com");
        msg.setSubject("JavaMail hello world example");
        msg.setSentDate(new Date());
        msg.setText("Hello, world!\n");
        Transport.send(msg);
    } catch (MessagingException mex) {
        System.out.println("send failed, exception: " + mex);
    }
\end{lstlisting}


			Nachteilig ist hier, dass die Konfiguration des Mailservers im Programmcode stattfindet.
			Abhilfe schafft die Definitiopn eiens Java Naming and Directory Interface (JNDI).
			\footnote{Um die Konfiguration zu verändern muss man auf die Admin Konsole (am Port 4848) zugreifen. Unter Ressourcen->Java Mail Session lassen sich die Einstellungen modifizieren.}
			Dort lassen sich Objekte und Daten ablegen und einheitlich abrufen. Hier wird es dazu benutzt
			das Sessionobjekt in GlassFish zu definieren und dann im Programmcode abzurufen.
			Die Session lässt sich nun mit einer Notation an ein Feld binden:
\begin{lstlisting}
	@Resource(name="mail/cismail")
	private Session mailSession;
\end{lstlisting}

			Der Programmcode ist nun unabhängig von der konkreten Serverkonfiguration.

			Zusätzlich zur Versendung von E-Mails an Benutzergruppen soll es zukünftig möglich sein,
			sich das Passwort zuschicken zu lassen.
\chapter{Praktische Umsetzung}
	
		Bei Rückgriff auf ein Framework ist die Gestaltung der Architektur zumeist eingeschränkt.
		JSF und Hibernate verlangen Java Beans\footnote{JSF verlangt, abweichend von der Definition, nicht,
		dass die Klassen das serializable Interface implementieren},
		JSF gibt das MVC Pattern vor. CIS befolgt strikt diese zwei Pattern.

		Die Strukturierung der Java Klassen in Packages erfolgt anhand von Funktionalität.
		Dies spiegelt die enge Verknüpfung zwischen
		dem Datenmodell und der dazugehörenden Container und Managed Bean wider. Durch diese Modularität
		ist das CIS3 erweiterbar. 

		Die Hauptarbeit, die das CIS erledigt, ist Verwaltung, Aufbereitung und Darstellung von Daten. 
		Die Aufbereitung der Daten übernehmen die Managed Beans, siehe dazu Kapitel 4.1. 		
		Kapitel 4.2 erläutert das MVC Pattern und wie es im CIS3 umgesetzt wurde.		
		In Kapitel 4.3 wird das zugrunde liegende Datenmodell erläutert. 
		Die Darstellung obliegt den Views, genaueres dazu in Kapitel 4.4.		
\section{Managed Beans}
		Die Managed Beans fungieren als Controller, bereiten die Daten zur Anzeige auf, beinhalten
		die Logik und speichern temporäre Informationen.
		Es gibt verschiedene Managed Beans. Sie unterscheiden sich durch die verwendeten Scopes
		auf der einen Seite und durch den konkreten Einsatzzweck auf der anderen Seite.
		Die in diesem Projekt
		verwendeten Scopes sind Application Scoped, Window Scoped und RequestScoped.
		Der zu verwendende Scope ergibt sich aus dem jeweiligen Einsatzzweck.
		Es sollte immer der niedrigst mögliche Scope verwendet werden. Je länger die Lebenszeit
		der einzelnen Managed Beans, desto größer ist auch der Speicherverbauch.
		Beans sind in aller Regel mit einer bestimmten Seite verknüpft. Die einzige Ausnahme sind 
		Application Scoped Beans sowie das Session und das Lecture Bean.
		
		Die Benutzerverwaltung und die Vorlesungsverwaltung sind Application Scoped. Dies bedeutet,
		dass sie solange vorgehalten werden wie die Anwendung auf dem Server läuft. Einhergeht damit auch,
		dass es jeweils genau eine Instanz gibt. Um dies sicherzustellen ist es naheliegend
		auf die Funktion der Managed Beans zurückzugreifen. Dies ermöglicht auch einen leichten Zugriff
		auf diese Instanz von allen Managed Beans aus.
		\footnote{Um das sicherzustellen, sollte die Option "`eager"'
		auf true gesetzt werden. Dies bedeutet, die Klasse wird direkt beim Starten der Applikation
		instanziert. Ohne diese Option wurde die Benutzerverwaltung mehrmals erstellt. Dies ist entweder
		ein Bug von JSF oder von ICEfaces.}
		
		Request Scope wird eingesetzt, wenn ein Formular ausgefüllt und abgeschickt wird, die Information
		aber nicht mehr benötigt wird. Exemplarisch sei hier die Login Seite genannt. 
		Es werden Benutzername und Passwort eingegeben. Nach erfolgreichem Einloggen werden diese Informationen
		jedoch nicht mehr benötigt. Hier ist es also ausreichend, die Klasse LoginManagedBean als
		RequestScoped zu deklarieren.
		
		Window Scoped ist ein von ICEfaces eingeführter Scope. Oft ist es notwendig Informationen
		über einen Request hinauszuspeichern oder es ist sinnvoll, um nicht immer wieder die gleiche
		Initialisierungsarbeit zu leisten. JSF bietet hierfür zwar den Session Scope an, welcher
		jedoch zu weitreichend ist. Es ist damit nicht möglich sich an einem PC mehrmals anzumelden.
		Um dies zu umgehen gibt es den Window Scope. Dieser hält ein Managed Bean solange vor, wie das
		zugehörige Browserfenster offen ist. Tabs werden dabei als getrennte Browserfenster betrachtet.
		So ist es nun möglich sich am gleichen PC mehrmals anzumelden.
		Window Scoped wird eingesetzt, wenn eine Seite über mehrere Requests offen ist und die Information
		erhalten bleiben soll. Wird etwa die Reihenfolge der News verändert, wird jedesmal ein Request
		an den Server geschickt. Request Scope würde hier einen sehr großen Rechenaufwand verursachen.
		
		Session Bean und Lecture Bean sind unabhängig von einer konkreten Seite.
		Das Session Bean wird eingesetzt um allgemeine Informationen über den Benutzer 
		über die gesamte Sitzung hinweg zu speichern. Es beinhaltet das User Objekt selber,
		zudem werden die belegten und administrierten Vorlesungen zwischengespeichert.
		Lecture Bean enthält alle Informationen, die über das Betrachten einer bestimmten
		Vorlesung hinweg benötigt werden. Es hält das Vorlesungsobjekt selber,
		zusätzlich speichert es die Menüs der Vorlesung sowie die 
		aktuell ausgewählten Menuitems.	
	
	\section{MVC Pattern}
		Das Model View Controller (MVC) Pattern schreibt die Einteilung eines Programmes in drei Teile,
		das Model, die View und den Controller, vor. Das Model hält die Daten, die View zeigt die aktuellen 
		Daten an und der Controller leitet aufbereitete Usereingaben an das Model weiter. 
		Das MVC Pattern ermöglicht es die View auszutauschen.
		Durch die Trennung der drei Teile werden die einzelnen Teile leichter wartbar.
		
		In JSF wird die View mit Hilfe von XHTML-Dateien definiert, 
		Model und Controller werden in Java geschrieben.
		Controller sind die Managed Beans, da nur durch sie eine Verknüpfung zwischen der View 
		(beschrieben mit XHTML) und dem zugehörigen Java Code möglich ist. 
		Diese Klasse enden alle auf "ManagedBean".
		\begin{figure}[hbt]
				\centering
				\includegraphics[scale=0.5]{MVC.png} 
				\caption{Architektur von CIS}
		\end{figure}
		Manchmal ist es notwendig, dass für ein Objekt für die Anzeige temporär Informationen gespeichert 
		werden, z.B. wenn eine News bearbeitet werden soll. Um das entsprechende Objekt mit dem
		Bearbeitungsstatus zu verknüpfen, kommen Containerklassen zum Einsatz. Dementsprechend 
		endet der Name dieser Klassen auf "`Container"'.
		Die restlichen Klassen bilden das Model. Ursprünglich waren diese Klassen POJOs
		\footnote{POJO steht für Plain old Java Objekt. Es bezeichnet Javaklassen, die gerade keiner Konvention
		unterliegen, steht also im Gegensatz von z.~B. Java Beans. Der Begriff geht auf
		Rebecca Parsons, Josh MacKenzie und Martin Fowler zurück, die einen griffigen Namen für
		gewöhnliche Objekte suchten: "`We wondered why people were so against using regular objects 
		in their systems and concluded that it was because simple objects lacked a fancy name. 
		So we gave them one, and it's caught on very nicely."'}, erst durch die 
		Anbindung mit Hibernate wurde es nötig, dass sie zu Java Beans erweitert wurden. 
		Die Logik ist in den Controller Klassen angesiedelt.
		
	\section{Datenmodell}
		Um ein Datenmodell zu entwickeln, ist erstmal eine gründliche Datenanalyse wichtig.
		Für das CIS ergaben sich zwei elementare Objekte: Auf der einen Seite gibt es die Benutzer des Sytems,
		auf der anderen die Vorlesungen.
		
		\subsection{Benutzer}
			Ein Benutzer (Klasse \emph{User}) besteht aus den persönlichen Informationen Namen, Matrikelnummer,
			E-Mail Adresse, belegtes Studienfach und angestrebter Abschluss.
			Zusätzlich hält er die Information über belegte Veranstaltungen mitsamt seiner Rolle in 
			der jeweiligen Vorlesung und angelegte Gruppen zum erleichterten Punkteeintragen.
			Mögliche Rollen sind Admin, Co-Admin, Tutor, Student und Gast. In jeder nicht belegten
			Vorlesung ist ein Benutzer Gast, in belegten Vorlesungen nach dem Belegen Student.
			Ein berechtigter Benutzer (zumeist Admin oder Co-Admin) kann eine andere Rolle zuteilen.
			Um alle Benutzer zu verwalten gibt es die Benutzerverwaltung (Klasse \emph{UserAdminManagedBean}).
			Diese hält alle registrierten Benutzer und 
			die verschlüsselten Passwörter. \footnote{als Verschlüsselungsverfahren kommt SHA-512 zum Einsatz.}
			Über die Benutzerverwaltung ist es möglich, neue Benutzer zu erstellen oder Benutzer
			anhand des Usernamens zu erhalten. Die Benutzerverwaltung ist auch für die Anbindung
			an Hibernate zuständig; In der Benutzerverwaltung erzeugte Benutzer werden auch in die
			Datenbank geschrieben.
			
		\subsection{Vorlesung}
			Vorlesungen bestehen aus sehr vielen Komponenten. Daher ist die Vorlesung nur ein Container,
			der alle Komponenten enthält. Konkret sind dies allgemeine Informationen 
			wie Name der Veranstaltung oder teilnehmende Benutzer so wie weitere
			Komponenten wie die Wahl von Übungsgruppen der Studenten,
			News, Arten von Übungsblätter, Übungsblätter, Zeiten für Übungsgruppen,
			Downloadkategorien, eingetragene Punktzahl für Übungsblätter, elektronische Abgaben
			der Studenten, versendete E-Mails, statische Seiten und Menu Items. 
			Im Folgenden eine kurze Auflistung und Erläuterung der einzelnen Komponenten einer Veranstaltung
			
			\subsubsection{Komponenten}
				\begin{itemize}
					\item{\textbf{Wünsche der Studenten:}} Melden sich Studenten für eine Vorlesung an,
						geben sie, sofern sie an den Übungsgruppen teilnehmen wollen, Wünsche
						für Übungsgruppen an. Damit später die Zuordnung korrekt erfolgt, müssen
						die Wünsche gespeichert werden. Hierzu werden die Wünsche in Kombination mit
						dem Usernamen gespeichert.
					
					\item{\textbf{News:}}
						Um Studenten aktuelle Informationen mitzuteilen, gibt es im CIS die News Funktion.
						Hiermit lassen sich Informationen erstellen, so dass auf einfache Weise Studenten
						über neue Klausurtermine, korrigierte Übungsblätter etc. informiert werden können.
						Eine News besteht aus einer Nachricht, einem optionalen Ablaufdatum und der Angabe,
						ob sie noch aktiv ist. Die Position, an der eine News angezeigt wird, ergibt
						sich aus der Position innerhalb der Liste. Dies alles kann von Benutzern,
						die Editierrechte haben, verändert werden.
					\item{\textbf{TaskCategory:}}
						Neben den Übungsblättern gibt es in manchen Vorlesungen noch weitere Kategorien,
						in denen Studenten Punkte und Noten erzielen können. In der Informatik I
						an der Uni Tübingen
						gibt es in der Regel zusätzlich noch Präsenzübungen, Einzel- und Gruppentestate.
						Die Punktzahlen werden jeweils getrennt voneinander berechnet. Daher ist es nötig,
						dass Übungsblätter in verschiedene Kategorien eingeordnet werden können.
						Hierfür gibt es die TaskCategory. Sie hat einen Namen, eine Gewichtung,
						eine Mindestanforderung und einen internen Zähler.
						In Vorlesungen wird die Endnote zumeist aus den erbrachten Leistungen während dem
						Studium und der Klausur berechnet. Damit diese Berechnung automatisiert erfolgen
						kann, gibt es die Möglichkeit die Gewichtung in Prozent anzugeben.
						Damit man mindestens eine vier bekommt, muss man eine gewisse Prozentzahl erlangen.
						Um einen Studenten zu informieren, ob er zu einem bestimmten Zeitpunkt die Anforderung
						erfüllt, muss die Mindestanforderung spezifiziert werden (in Prozent).
						Mit Hilfe des internen Zählers wird die Erstellung eines neuen 
						Übungsblattes erleichtert,
						indem der neue Name eines Übungsblattes aus dem Namen der TaskCategory
						und des Counter generiert wird; dieser Name kann modifiziert werden.
					\item{\textbf{ExerciseSheet:}}
						Ein Übungsblatt umfasst eine Reihe von Informationen: Einen Namen
						für das Übungsblatt , ein Datum, an dem das Übungsblatt veröffentlicht wird, 
						ein Datum, an dem das Übungsblatt abgegeben werden muss, 
						das Übungsblatt und optional die Musterlösung in digitaler Form (zumeist als PDF),
						die Korrekturzeit, innerhalb derer die Tutoren die Punktzahl eintragen müssen, und
						die Kategorie, zu der das Übungsblatt zugeordnet werden soll.
						
						Außerdem kann man
						Aufgaben und digitale Abgaben spezifizieren. Aufgaben haben einen Namen,
						eine maximale Punktzahl und können als Bonusaufgabe gewertet werden, d.h.
						die Punktzahl wird nicht auf die erforderliche Gesamtpunktzahl addiert. Somit können
						mehr als 100\% der Punkte erreicht werden.
						
						Es gibt zudem die Möglichkeit, dass Studenten digitale Lösungen einreichen.
						Hierfür muss angegeben werden, wie viele Abgaben und welcher Art möglich sind. 
						Eine digitale Abgabe
						hat einen Namen und ein Präfix, der an den Dateinamen später angehängt wird.
						Eine digitale Abgabe kann ein von dem Übungsblatt abweichendes Rückgabedatum haben.
					\item{\textbf{MeetingDate:}}
						Es gibt einige Veranstaltungen, die von sehr vielen Studenten belegt werden. Für
						diese Vorlesungen werden mehrere Übungsgruppen angeboten. Wenn sich Studenten 
						für eine solche Veranstaltung registrieren ist es sinnvoll, dass sie sich nicht für 
						eine bestimmte Übungsgruppe, sondern für bestimmte Zeiten anmelden.
						So lässt sich eventuell noch flexibel auf die Verteilung eingehen und es können
						für beliebte Zeiten mehrere Übungsgruppen angeboten werden. Daher braucht es 
						auch eine Repräsentation für Zeiten. \footnote{Ansonsten ließe sich, wie für den Ort,
						eine einfache Stringrepräsentation wählen} 
						Ein MeetingDate besteht aus aus einer Startzeit und aus einer Dauer.
					\item{\textbf{DownloadCategory:}}
						Begleitend zu einer Vorlesung ist es öfters notwendig, den Studenten Downloads
						anzubieten, etwa Vorlesungsskripte oder Beispielcode. Zur besseren Übersicht bietet
						es sich an die Downloads in Kategorien zu ordnen. Dies bewerkstelligt DownloadCategory.
						DownloadCategory hat einen Namen und eine Liste von Downloads.
						Downloads können entweder externe Links sein oder hochgeladene Dateien.
						Beiden haben einen Namen und ein Datum, zu dem sie hochgeladen wurden.
					\item{\textbf{ScoreData:}}
						Die von Tutoren eingegebenen Punkte müssen gespeichert werden. Hierfür
						gibt es eine Map, die als Key das Übungsblatt und als Value ScoreData enthält.
						ScoreData fungiert als Container, es enthält selber nur ein Feld. 
						\footnote{Dies ist notwendig, weil Hibernate keine mehrfach verschachtelte Maps
						verarbeiten kann. Aus dem selben Grund gibt es HandingInData}
						Das Feld ist wieder eine Map, mit dem Benutzernamen als Key
						und eine Liste von Score Objekten als Value. 
						
						In Score Objekten werden die Punktzahl und der Status gespeichert. Es gibt
						vier Zustände: "`Noch nicht eingetragen"', "`bearbeitet"', "`entschuldigt"' oder 
						"`nicht bearbeiten"'.
						Wird eine Aufgabe als entschuldigt markiert, wird diese aus der Wertung genommen.
						Der Status "`nicht bearbeitet"' ist bei der Wertung gleichbedeutend mit "`bearbeitet"'
						und 0 Punkten. Es dient allein der statistischen Erfassung. 
						Anhand des Status "`Noch nicht eingetragen"' können Studenten unterscheiden,
						ob ihre Punktzahl bereits eingetragen wurde oder ob sie 0 Punkte auf eine Aufgabe
						bekommen haben.	
					\item{\textbf{HandingInData:}}
						Studenten können digitale Lösungen für bestimmte Aufgaben abgeben.
						Diese werden in einer Map gespeichert. 
						So lässt sich in linearer Zeit auf jede Abgabe zugreifen.
					\item{\textbf{Mail:}}
						Das CIS bietet die Möglichkeit, E-Mails an bestimmte Benutzergruppen
						zu verschicken. Damit es möglich ist bereits versendete E-Mails später zu betrachten,
						gibt es ein Archiv dafür. Ein Mail Objekt repräsentiert eine versendete Mail.
						Es speichert den Absender, die Empfängergruppe, Betreff, den Nachrichtentext
						und das Datum, an welchem die E-Mail abgeschickt wurde.
					\item{\textbf{StaticPage:}}
						Um den Studenten weitergehende Informationen zu einer Vorlesung anzubieten, wie
						etwa Literaturlisten oder eine Übersichtsseite mit allgemeinen Informationen wie
						Klausurtermine,
						benötigt man statische Seiten. Diese können durch die Dozenten völlig frei gestaltet
						werden. Es gibt keine Beschränkung in Anzahl, die Eingabe erfolgt durch einen
						Rich Text Editor. Zu jeder statischen Seite wird der Name (der eindeutig sein muss!)
						und der Inhalt gespeichert.				
					\item{\textbf{LectureMenuItem:}}
						Die Navigation einer Vorlesung erfolgt über ein zweigliedriges Menü.
						Es gibt MenuCategory um die erste Ebene darzustellen und LectureMenuItem für
						die zweite Ebene. MenuCategory hat neben einem Namen eine Liste von LectureMenuItem
						und Zugriffsrechte. LectureMenuItems haben ebenfalls einen Namen und Rechte,
						dazu noch einen Link auf die jeweilige Seite.
						Für eine bestimmte Seite gibt es immer genau ein LectureMenuItem.
				\end{itemize}
			Um die Vorlesungen zu verwalten gibt es eine Vorlesungsverwaltung(LectureAdminManagedBean).
			Die Benutzerverwaltung erstellt neue Vorlesungen und meldet diese bei den im System vorhandenen
			Benutzer an. 
			
	
			
	\section{View}
		Die Oberfläche des CIS soll einfach zu bedienen, übersichtlich, ästhetisch und einfach gehalten sein. 
		
		
		\subsection{Komponenten}
			\subsubsection{Darstellung von Collections} 
					Oft müssem Daten angezeigt werden, deren Länge variieren können (z.B.
					Anzeige aller Benutzer). Für dieses immer wiederkehrende 
					Problem gibt es mehrere Komponenten, die ICEfaces zur Verfügung stellt.
					Es gibt ice:repeat, ice:panelSeries, ice:columns, ice:menuItems und ice:dataTable.
					Allen Komponenten gemein ist, dass sie entweder ein Array oder eine Collection
					als Datenquelle nutzen können. Ändert sich diese, verändert sich automatisch die Ansicht.
					Will man also ein Element löschen, muss man nur im Hintergrund das entsprechende 
					Element entfernen. Die Ansicht wird ohne weiteres Zutun aktualisiert.
					Die Komponenten funktionieren ähnlich einer for-each Schleife in Java.
					Es lässt sich auch hier eine Variable definieren, auf der man Zugriff
					auf das aktuelle Element hat. 
\begin{lstlisting}
<ice:panelSeries value="#{managedBean.objekte}"
		var="objekt">
	<ice:outputText value="#{objekt} />
</ice:panelSeries>
\end{lstlisting}	
					Dies würde über alle Objekte des Feldes \emph{Objekte} iterieren und den Namen anzeigen.
					Angenommen es existiert die Methode "`removeObjekt"' bereits in der Klasse Managed Bean, 
					dann kann man folgendermaßen ein Objekt aus der Liste löschen:
\begin{lstlisting}
<ice:panelSeries value="#{managedBean.objekte}"
		var="objekt">
	<ice:outputText value="#{objekt} />
	<ice:commandButton value=loeschen"
			action=#{managedBean.removeObjekt(objekt)} />
</ice:panelSeries>
\end{lstlisting}			
					Hier sieht man auch den Vorteil, den parametrisierte Methodenaufrufe in der EL
					bringen: Könnte man das Objekt nicht mitgeben, müsste über das Event
					erst die outputText Komponente gefunden werden, über diese müsste man den
					Namen des Objektes herausfinden, um dann das richtige Objekt
					finden und anschließend zu löschen.
					Definiert man in der Komponente den sogenannten
					varStatus analog zur Definition der Variable,
					kann man damit die aktuelle Zeile und die Anzahl der Zeilen herausfinden:
					\footnote{die Variable führt auch noch Informationen über den Start
					(standardmäßig eins) und zwei Flags mit, die angeben, ob es sich um die erste oder die
					letzte Zeile handelt.}
\begin{lstlisting}
<ice:panelSeries value="#{managedBean.objekte}"
		var="objekt"
		varStatus="status">
	<ice:outputText value="Zeile #{status.index} von #{status.end}" />
	<ice:outputText value="#{objekt} />
</ice:panelSeries>
\end{lstlisting}						

					\vspace{5mm}					
					
					Die oben aufgeführten Komponenten rendern zwar alle beliebig viele Elemente,
					jedoch hat jede sein spezifisches Einsatzgebiet.
					Das bereits vorgestellte ice:panelSeries rendert alle Kinder in einem Panel. So lassen sich 
					komplexe Gruppen von Komponenten erstellen.
					ice:repeat ist ähnlich zu ice:panelSeries, erzeugt jedoch keine Komponente.
					Das ist manchmal erforderlich, etwa wenn man eine Tabelle definiert. Es hat aber den
					Nachteil, dass man selber Sorge tragen muss,
					dass die Komponenten trotz fehlendem Panel übersichtlich angeordnet werden.
					Erstellt man ein Menü mit dynamischen Einträgen, 
					so muss man auf ice:menuItems zurückgreifen. Es rendert alle in der Backing
					Bean erstellten Menü Items.
					ice:dataTable rendert ein HTML Table, dabei entspricht jedes Element einer 
					Collection einer Reihe. Eine DataTable bietet noch einige weitere Funktionen,
					etwa Sortierbarkeit oder Beschränkung der Anzeige auf eine bestimmet Anzahl an Reihen.
					Mit ice:columns kann man eine variable Anzahl an Spalten innerhalb einer Data Table
					rendern.		
				\subsubsection{Eingabekomponenten}
					Die Bibliothek von ICEfaces bietet aus HTML bekannte Eingabekomponenten 
					und fügt noch weitere hinzu. HTML Komponenten, wie etwa
					ein Texteingabefeld oder Checkboxen werden um ICEfaces Funktionalität, wie 
					etwa partialSubmit erweitert. Für Komponenten, bei denen man aus bestimmten
					Optionen auswählt, etwa Listboxen oder Drop-Down Menüs, ist es erforderlich
					einen Konverter zu schreiben, wenn diese andere Werte als Basistypen enthalten.
					\footnote{Wie ein Converter genau funktioniert und geschrieben werden muss,
					wird im Developers Guide genauer erläutert}
					Im Folgenden exemplarisch einige der von ICEfaces neu eingeführten Komponenten.
										
					\emph{DateTimeEntry} ermöglicht die Eingabe eines Datums über einen Kalender.
					Es lässt sich einstellen, ob man zusätzlich eine Zeit angeben will.
					Der Kalender kann als Pop Up gerendert werden um Platz zu sparen. 
					Es lässt sich auch ein Eingabefeld dazuschalten, damit die Eingabe
					weiterhin manuell erfolgen kann. 
					\begin{figure}[hbt]
						\centering
						\includegraphics[scale=1]{date.png} 
						\caption{Ein Date Time Entry}
					\end{figure}
					
					\emph{InputRichText} erlaubt es Text einzugeben und diesen zu formatieren. 
					Gespeichert wird der Text als HTML Code.
					
					\emph{FileEntry} ermöglicht es Dateien auf den Server hochzuladen.

					Mit \emph{MenuBar} lassen sich Menüs erstellen. Diese können dank Hover Effekt
					sehr platzsparend erstellt werden. Die Menüs lassen sich mit Hilfe von CSS
					an das jeweilige Design anpassen.
					
				\subsubsection{Ausgabekomponenten}
					Neben den genannten gibt es noch weitere nützliche Komponenten.
					Mit \emph{outputResource} lassen sich Dateien, die auf dem Server liegen, herunterladen.
					Der Ort der Datei wird dabei zur erhöhten Sicherheit verborgen.
					
					\emph{outputProgress} erzeugt einen Fortschrittsbalken. Entweder zeigt er den prozentualen
					Fortschritt an oder er unterscheidet nur zwischen "`in Arbeit"' und "`fertig"'.
					
					\emph{dataExporter} ermöglicht es, eine Data Table entweder im
					Excel oder CSV Format zu exportieren .
\chapter{Fazit}
	Das hier vorgestellte CIS3 ist ein großer Schritt in Richtung einer neuen Vorlesungsplattform.
	Zur Zeit beherrscht es fast alle Funktionen des CIS2. Es fehlt bislang noch Unterstützung für
	Präsenzübungen,
	Anbindung an einen SVN Server und ein Wiki. Der restliche Funktionsumfang wurde komplett abgebildet.
	Darüber hinaus sind schon einige neue Funktionen eingeführt worden.
	
	Das System erlaubt für alle Veranstaltungen, die auf dem CIS3 laufen, nur noch eine einzige 
	Registrierung. Zu neuen Vorlesungen hat man
	sich mit zwei Klicks angemeldet. Zusammen mit einer Übersicht von belegten Vorlesungen wird auch verhindert, 
	dass Studenten vergessen sich für eine
	Vorlesung oder sich mehrmals für die selbe Vorlesung anzumelden.
	
	Die Möglichkeit im CIS3 Teams von Studenten für Gruppenarbeit zu definieren beschleunigt das 
	Eintragen von Punkten erheblich. Punktezahlen mit Status wie "`bearbeitet"' oder "`entschuldigt"' 
	zu verknüpfen bringt viele Vorteile mit: Die Berechnung der Endnote wird vereinfacht und 
	für Studenten ist es sofort unterscheidbar, ob Punkte bereits eingetragen wurden oder nicht.
	Die manuelle Berechnung der Entnote und Rückfragen unsicherer Studenten entfällt. 
	Dozenten haben die Möglichkeit, die Sichtbarkeit von statischen Seiten genauso zu behandeln wie die der
	restlichen Seiten. Es ist also möglich, öffentlich zugängliche, aber auch nur für bestimmte
	Benutzergruppen sichtbare statische Seiten anzulegen.
	
	Damit das vorliegende CIS3 das alte CIS2 ablösen kann, bedarf es aber noch Arbeit. Für die Vorlesungen
	Informatik I/II ist CIS3 erst interessant, wenn damit Präsenzübungen durchgeführt werden können.
	Für die Vorlesung Software Engineering ist die Nutzung von SVN/Mercurial und Trac unabdingbar. 
	Auch das Wiki sollte gerade bei größeren Vorlesungen integriert sein.
	
	Der neue Aufbau des CIS ermöglicht weitere Funktionen, die die Benutzbarkeit erheblich
	erhöhen würden.
	
	Denkbar wäre eine Startseite, auf der alle Neuigkeiten übersichtlich gelistet sind, z.~B.
	News, neu veröffentlichte Übungsblätter, die Information über eingetragene Punkte oder eine Erinnerung,
	dass die Lösung zu einer Aufgabe bald abgegeben werden muss.
	Gerade bei größeren Vorlesungen haben nach der Zuteilung der Übungsgruppen viele Studenten den Wunsch,
	in eine andere Übungsgruppe zu wechseln. Dies bereitet nicht nur den Dozenten Arbeit,
	sondern es werden zum Teil Plattformen für die Gesuche genutzt, die dafür nicht angedacht waren,
	z.~B. die Mailingliste "info-studium". Eine Art Marktplatz hierfür würde sowohl die Arbeit der 
	Dozenten reduzieren als auch Konflikte auf den verschiedenen Mailinglisten reduzieren. Auch für
	die Studenten würde sich vieles vereinfachen, da nun eine einheitliche Plattform zum Übungsgruppentausch
	geschaffen wäre.
	
	Bisher ist es noch nicht möglich, direkt die Endnote zu berechnen. Die erreichte Prozentzahl, auch
	mit der korrekten Gewichtung, lässt sich zwar im CIS3 
	berechnen, die Umwandlung der Prozentzahl in die tatsächliche
	Note ist aber noch nicht möglich. Die Grundlagen für diesen Schritt sind
	dank der Status für bearbeitete Aufgaben aber schon gelegt.		
	
	Nach Umsetzung der geplanten Eigenschaften und einer umfassenden Testphase, kann CIS3 die Arbeit von 
	Dozenten und Tutoren noch weiter erleichtern und den Studenten eine übersichtliche Hilfe sein.			
					
\appendix
\chapter{Developers Guide}
	
	Um Interessenten, die das CIS3 erweitern wollen, den Einstieg zu erleichtern, wird hier ein 
	kleiner Leitfanden vorgelegt.
	Er soll helfen, Fallstricke zu umgehen und bietet für einige Probleme eine passende Lösung.
	Außerdem sind hier einige Eigenheiten und Bugs dokumentiert, 
	über die ich selber während meiner Bachelorarbeit gestolpert bin.	
	
	
	\section{Bugs}
		Im Folgenden will ich ein paar Bugs dokumentieren, die mir aufgefallen sind	.
		Diese sind bereits auf den Bug Trackern dokumentiert, im aktuellen Release aber noch vorhanden.
		\begin{itemize} 
			\item \emph{DataTable in DataTable}: Es kommt öfters vor, dass man DataTable verschachteln will,
				  etwa wenn man alle Übungsgruppen anzeigen und dort alle Tutoren auflisten will.
				  Es werden aber mit jedem Aufruf der Seite leere Zeilen hinzugefügt, mit jedem Aufurf
				  verdreifacht sich so die Anzahl der Zeilen. Dies lässt sehr schnell den Server
				  zusammenbrechen.
				  Dieses Problem tritt auch auf, wenn man PanelSeries verwendet oder die beiden kombiniert.
				  ui:repeat scheint dieses Problem zu lösen, erzeugt aber ein neues Problem:
				  Alle gerenderten DataTables haben die gleiche ID, es wird somit immer nur die 
				  Letzte gerendert. Mit c:forEach trat dieses Problem nicht auf. 
				  \footnote{Es ist sehr unschön, auf JSP zurückzugreifen. Das Problem könnte eventuell
				  auch mit ice:repeat umgangen werden}.
				  c:forEach ist eigentlich ein JSP Element und wird dort benutzt, um über Collections
				  zu iterieren. Sollte das Problem mit einem neuen ICEfaces Release behoben sein,
				  sollte dieser Workaround sofort wieder abgeändert werden.
			\item Application Scoped Beans: Während der Entwicklung fiel auf, 
				  dass die Benutzerverwaltung mehrmals erzeugt wurde. Wird 
				  ein Objekt der Benutzerverwaltung erzeugt, darf es als Application Scoped
				  Bean erst am Programmende zerstört werden. Einher geht damit, dass keine zweite Instanz
				  existieren darf, sonst ist es nicht mehr eindeutig ansprechbar. Trotzdem trat dieser Fall
				  auf. Um das Problem zu lösen hat es gereicht, in der Benutzerverwaltung die Option
				  "`eager"' auf true zu setzen. Eager gibt an, ob ein Objekt direkt zum Start der
				  Applikation erzeugt werden soll. Ansonsten wird das Objekt erst erzeugt, wenn es zum
				  ersten Mal benutzt wird. Definiert wird eager in der Annotation der Managed Bean,
				  also:
				  \begin{lstlisting}
				  	@ManagedBean(name="userAdminBean", eager=true)
				  \end{lstlisting}
				  Durch diese Änderung wurde die Benutzerverwaltung direkt bei Programmstart erzeugt.
		\end{itemize}
		
	\section{Problemstellungen}
		\subsection{Eine Component soll den Wert einer anderen Component ändern}
			Auf den ersten Blick erscheint es simpel: Will man den Wert einer anderen Component
			ändern, ändert man einfach den dazugehörigen Wert im Backing Bean.
			Als Beispiel sei die Punkteeingabe genannt: Ändert sich der Wert im Punktefeld,
			soll der Status automatisch auf "`Eingegeben"' geändert werden.
			Dies erleichtert die Eingabe enorm. 
			
			Der erste Ansatz, beim Aufruf des ValueChangeListener des Eingabefeldes 
			den Wert des Status in Backing Bean zu ändern, scheitert. Um die Ursache zu
			verstehen muss man den Lebenszyklus genauer betrachten. Der Aufruf des ValueChangeListener
			erfolgt in der Apply Request Phase, also schon in der zweiten Phase. Hier wird nun 
			der Wert im Backing Bean geändert auf "Bearbeitet". 
						
			In der übernächsten Phase, der Update Model Values Phase, wird den Werten im Backing Bean
			der Wert der Component zugewiesen. Dieser Wert hat sich aber nicht geändert,
			er ist in diesem Fall immer noch auf "Nicht eingetragen". Nach dieser Phase
			ist der Wert im Backing Bean also "Nicht eingetragen". Danach werden die Components erstellt
			und der Wert der Components werden aus dem Backing Bean übernommen.
			Da der Wert auf "`Nicht eingetragen"' steht, hat letztendlich nichts verändert.
			Um das Problem zu lösen gibt es zwei Möglichkeiten. Der erste Ansatz wäre,
			direkt den Wert der Component zu ändern. Dazu muss man die Component in das Backing Bean binden.
			Im ValueChangeListener ändert man den Wert der Component, der dann in der vierten
			Phase auch in das Backing Bean übertragen wird.
			In einer Testapplikation funktionierte dieser Ansatz sehr gut. In der eigentlichen Applikation
			leider nicht, anscheinend hat ICEfaces Schwierigkeiten Components innerhalb einer
			DataTable zu binden. 
			
			Ein anderer, leichter Ansatz ist die Möglichkeit Events auf eine spätere Phase zu verschieben.
			Es gibt die Möglichkeit, Events wieder in die Eventqueue zurückzustecken und zu 
			einer späteren Phase wieder auftauchen zu lassen. Wenn das Event nach der Update Model Values
			Phase verarbeitet wird, wird die Änderung des Wertes in der Backing Bean nicht überschrieben.
			Wird der Event Listener also in der Invoke Application Phase verarbeitet, haben wir unser Ziel
			erreicht. Dies alles erreicht man durch folgende Änderung des Value Change Listener:
\begin{lstlisting}
public void listener(ValueChangeEvent v) {
	if (v.getPhaseId().equals(PhaseId.ANY_PHASE)) {
		//Event wird zurueck in die Queue geschickt
		v.setPhaseId(PhaseId.INVOKE_APPLICATION);
		v.queue();
	} else { //Do something }
}
\end{lstlisting}			
			Mit dieser kleinen Änderung kann man also auch Werte anderer Components verändern.
			Anhand der Punkteingabe kann man das sehr schön beobachten:
			Sobald sich der Wert geändert hat, d.h. sobald nach der Eingabe
			das Feld seinen Fokus verliert, ändert sich auch die zugehörige Drop Down Box.
		\subsection{Wie kann ich auf ein anderes Managed Bean zugreifen?}
			Oft kommt man in die Situation, dass man irgendwo in einer Java Klasse
			auf ein fremdes Managed Bean zugreifen will. Will man etwa eine Vorlesung hinzufügen,
			möchte man auf das Lecture Admin Bean zugreifen. Doch wie bewerkstelligt man das?
			Es gibt prinzipiell zwei Möglichkeiten: Entweder durch Injection über den FacesContext.
			Injection bedeutet, dass JSF sich darum kümmert Werte in ein Feld zu schreiben.
			Dazu deklariert man ein Feld per @ManagedProperty Annotation als verwaltetes Feld.
			Man muss natürlich noch den Wert definieren, der in diesem Feld stehen soll.
			Angenommen man will das Session Bean in diesem Feld haben, lautet die Annotation\\
			@ManagedProperty(value="\#\{sessionBean\}")
			Man definiert den Inhalt also per EL. Nun kann man einfach auf das Feld
			und somit auf die Managed Bean zurückgreifen.
			
			Leider gibt es auch hier einen Nachteil. Gerade wenn man auf ein Bean mit dem gleichen Scope
			zurückgreifen will, kann Lazy Creation eine NullPointerException verursachen.
			Lazy Creation sorgt dafür, dass ein Managed Bean erst dann generiert wird,
			wenn es tatsächlich benötigt wird. Es kann daher nicht garantiert werden,
			dass ein Bean schon erstellt wurde, wenn man darauf zugreifen will.
			Beans mit einer geringeren Lebensdauer sollten sowieso nicht per Injection eingebunden werden.
			Das Problem kann durch Abschalten von Lazy Creation gelöst werden (hierzu die Option eager
			auf true setzen), jedoch geht damit auch der geringere Speicherverbrauch von Lazy Creation
			verloren. 
			
			Die andere Möglichkeit ist auf den FacesContext zurückzugreifen. Man kann mit Hilfe
			von dem Context direkt EL Code auswerten lassen. Das funktioniert zum Beispiel folgendermaßen:
\begin{lstlisting}
FacesContext context = FacesContext.getCurrentInstance();
LectureManagedBean lb = context.getApplication.
		evaluateExpressionGet(context, "#{lectureBean}", LectureManagedBean.class);
\end{lstlisting}
		\subsection{Wie verwende ich Auswahlkomponenten}
			Wenn man dem Benutzer eine Auswahl z.B. von verschiedenen Übungsgruppen 
			zur Verfügung stellen will, entsprechen die Werte
			der Auswahl nicht immer Basistypen. Dadurch wird auch im Backing Bean die
			Auswahl als Übungsgruppe gesetzt. Das zu erreichen ist etwas umständlich.
			Im Folgenden wird anhand des SelectOneMenu erklärt, bei den anderen Komponenten
			funktioniert es analog.
			
			Die erste Idee, einfach das f:selectItems mit der Collection der Werte zu übergeben, funktioniert
			nicht. Die Objekte werden einfach durch die toString() Methode in Strings verwandelt,
			der Wert der Ausgabe ist somit ein String. Man muss eine Liste von SelectItems erstellen,
			als Value das Objekt, das hinterlegt werden soll, und als Beschreibung den Text,
			der später im SelectOneMenu stehen soll. 
			Bindet man jetzt den Wert von SelectOneMenu an ein Feld, muss dieses Feld ein SelectItem
			sein. Liest man den Value dieses SelectItem aus, wird man vermutlich überrascht sein:
			Man bekommt einen String und nicht das gewünschte Objekt. 
			Das Problem ist: Das Objekt wird zur Anzeige in ein String überführt. ICEfaces weiß jedoch für
			unbekannte Objekte nicht, wie es einen String wieder in ein Objekt überführt.
			
			Dieses Problem lösen Converter. Converter sind Java Klassen, die das Converter Interface
			implementieren. Sie haben dann eine getAsObject und eine getAsString Methode,
			die ein Objekt in seine String Darstellung und vice versa überführt. Wie die getAsString
			Methode zu implementieren ist, ist meist nicht sehr schwierig. Interessanter ist die
			getAsObject Methode, denn in aller Regel enthält die String Repräsentation nicht alle 
			Informationen um daraus ein neues Objekt zu konstruieren. Daher muss die String Repräsentation
			eindeutig sein, damit man anhand derer das richtige Objekt finden kann.
			
			Der Trick: Man geht alle SelectItems durch. Sobald die Beschriftung des SelectItem
			mit dem String übereinstimmt, hat man das richtige Objekt gefunden. Das Ganze
			sieht dann, wie hier beispielsweise für Übungsgruppen, so aus:
			
\begin{lstlisting}
public Object getAsObject(FacesContext fc, UIComponent uic, String string) {
	if (string.equals("Keine Uebungsgruppe"))
		return null;
		UISelectOne listBox = (UISelectOne)uic;
		// search the UISelectItems list in the ListBox children
		for (UIComponent child : listBox.getChildren()) {
			if (child instanceof UISelectItems) {
				// found it, now get the real SelectItem list
				UISelectItems items = (UISelectItems)child;
				List<SelectItem> realitems = (List<SelectItem>) items.getValue();
				// search for the selected exercise group and return it
				for (SelectItem item : realitems) {
					ExerciseGroup w = (ExerciseGroup)item.getValue();
					if ((w!= null) && (w.getName().equals(string))) {
						return w;
					}
				}
			}
		}
	throw new AssertionError("Exercise Group not found");            
} 
\end{lstlisting}
	

			Wichtig ist: Hat man in seiner Auswahlliste ein Item, um die Auswahl zurückzusetzen, 
			mit dem Wert null,
			muss dies im Converter abgefangen werden.
			Vor der Verwendung des Converters muss dieser registriert werden, am besten per
			Annotation:
\begin{lstlisting}
@FacesConverter(value="exerciseGroupConverter")
\end{lstlisting}
			Der Name ist natürlich frei wählbar, es bietet sich aber an einer Konvention zu folgen.
			Hier ist der Name immer die Kombination aus dem Klassennamen und Converter,
			Anfangsbuchstabe klein (wie bei den Managed Beans).
			
			Ist der Converter registriert, kann man ihn nun als Kind-Komponente eines  SelectOneMenu verwenden:
\begin{lstlisting}
<ice:selectOneMenu value=#{bean.exerciseGroup}>
	<f:selectItems value=#{bean.getExerciseGroupItems} />
	<f:converter converterId="exerciseGroupConverter" />
</ice:selectOneMenu>
\end{lstlisting}
			Nun funktioniert alles einwandfrei.
	
\chapter{Benötigte Bibliotheken}
		Um den Programmcode von CIS3 zu übersetzen, werden einige Bibilotheken benötigt.
		Zum einen ergeben diese sich aus den bereits erwähnten Technologien, andere für kleinere
		Methoden, auf die zurückgegriffen wurde.
		Hibernate benötigt neben den eigenen Bibliotheken auch noch slf4j, damit es lauffähig ist.
		Zur Verschlüsselung wurde auf die Apache Commons Bibliothek zurückgegriffen.
		Java Mail benötigt in diesem Fall keine weiteren Bibliotheken, da es sich um eine Java EE
		Anwendung handelt. Für gewöhnliche Java Anwendungen müsste die entsprechende Bibliothek
		eingesetzt werden.
		Konkret müssen also folgende JAR Dateien in den Classpath der Anwendung vorhanden sein:
		\begin{itemize}
			\item JSF
				\begin{itemize}
					\item jsf-api.jar
					\item jsf-impl.jar
				\end{itemize}
			\item ICEfaces
				\begin{itemize}
					\item icefaces-compat.jar
					\item commons-loggin-1.1.jar
					\item krysalis-jCharts-1.0.0-alpha-1.jar
					\item jxl.jar
					\item icepush.jar
					\item icefaces.jar
					\item icefaces-ace.jar
				\end{itemize}
			\item Hibernate
				\begin{itemize}
					\item cglib-2.2.2.jar
					\item commons-codec-1.5.jar
					\item antlr-2.7.6.jar
					\item commons-collection-3.1.jar
					\item commons-lang-2.4.jar
					\item dom4j-1.6.1.jar
					\item hibernate-commons-annotations-3.2.0.Final.jar
					\item hibernate-core-3.6.3.Final.jar
					\item lucene-core-3.1.0.jar
					\item slf4j-api-1.6.1.jar
					\item hibernate-jpa-2.0-api-1.0.1.Final.jar
					\item slf4j-simple-1.6.1.jar
				\end{itemize}
			\item Je nach verwendeter Datenbank muss noch der jeweils passende Driver für Hibernate 
					eingebunden werden		
		\end{itemize}
	\bibliographystyle{plain}
	\bibliography{cites}
\end{document}
			